NOTES:

1. APIs are transparent

2. Types of APIs:

   1. Private
   2. Public
   3. Partner

3. API security Domain:

   1. Portal - publishes keys for the API (Keys are published on these portals and used by Developers to develop applications)

   2. API - Allows granular-level access to systems and productivity tools

   3. Application - uses the API to communicate with the microservices

   4. User - use the app that interacts with API or uses API to communicate with the microservices

   5. Developer - uses the API to develop an application

   6. Admin - produces and maintains the APIs.

   7. API vulnerability will provide a more diverse and granular level of access to the server as compared to a compromised application or website.

   8. Private APIs can be visible to public internet if not secured properly, private doesn’t mean secure.

   9. TOP 10 OWASP 2024(not updated since last update 2023) https://owasp.org/API-Security/editions/2023/en/0x11-t10/:

      1. Broken object level authorization - Object-level authorization (OLA) is an access control mechanism that determines which users can perform actions on specific data objects in an application. (mitigation - Object level authorization checks on functions accessing a data source using an ID from the user)
      2. Broken Authentication - implementation flaws to assume other users identitites temp or permanently.
      3. Brokern Object property level Authorization - combines excessive data exposure and mass assignment, Object property level authorization (OPLA) is a security control that allows administrators to limit access to specific object properties or attributes based on user roles or permissions.
      4. Unrestricted Resource Consumption - mitigation a rate limit mechanism should be implemented
      5. Broken Function level Authorizatoion - Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws.
      6. Unrestricted Access to sensitive business flows - APIs vulnerable to this risk expose a business flow - such as buying a ticket, or posting a comment - without compensating for how the functionality could harm the business if used excessively in an automated manner.
      7. server side request forgery - Server-Side Request Forgery (SSRF) flaws can occur when an API is fetching a remote resource without validating the user-supplied URI.
      8. security misconfigurations - APIs and the systems supporting them typically contain complex configurations, meant to make the APIs more customizable.
      9. improper inventory management - APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important.
      10. unsafe consumption of APIs - Developers tend to trust data received from third-party APIs more than user input, and so tend to adopt weaker security standards.

   10. Mitigating API threats:

       1. Rate limiting - limits the amount of time a service can be requested.
       2. Message validation - validates incoming and outgoing messages (messages are usually JSON containing functions that is a way to communicate with APIs)
       3. Access control - restricts API usage based on identity
       4. Encryption - MITM and spoofing are mitigated
       5. OpeinID connect and OAuth have been introduced for authentication and SSL/TLS has been implemented to enable encryption of communication channel.
       6. TLS trust attack:
          1. CA vuln:
             1. trusted CA compromised and is used to issue malicious certificates.
          2. Human Vuln:
             1. weakest link
          3. MITM:
             1. if the channel is using vulnerable ssl/tls protocol, the coomunication can be sniffed and the packets can be decoded with a amount of experience
       7. HTTP access control:
          1. basic authentication - request header contains password and username in plaintext which is base64 encoded (there is difference between encoding and encrypting) encoding doesn’t mean it is secure and confidential, it means that the data is obfuscated.
          2. Digest authentication - password is encrypted, server can downgrade the scheme to basic, vuln to man in the middle attack.

   11. Best security practices:

       1. authentication and authorization of users
       2. check for OWASP top 10 vulnerabilities
       3. Throttling (rate limiting the services)
       4. Continuous API monitoring to detect over-usage
       5. Request/response payload validation
       6. Error handling (to prevent unwanted information disclosure)

   OAuth2:

   1. An authorization protocol that authorizes a user without sharing a username and password, a Oauth access token is issued and accepted for an authorized user at an API endpoint.
   2. Access controls:
      1. traditional access controls are built in such a way that they assume there are two parties involved and access controls are planned assuming two parties.
      2. These access controls are ineffective in the case of APIs. To illustrate an external developer develops an app using the API users do not trust the external developer to share their credentials to utilize the API, this kind of trust problems can be solved with the help of OAuth.
      3. Oauth prescribes a standardize way to access 3rd party resources in a secure and authorized way.
   3. Code flow for OAuth:
      1. App registers and authenticates and authorizes itself with the provider to get access to API services
      2. API needs to know the application name and callback URL for redirections.
      3. API provides the app with clientID(Public identifier encoded in multicharacter hex string) and client secret (Known only to the authorization API server and app, secret is a 256bit value that is converted to corresponding hex value by encryption)
      4. resource scope determines what kind of access an app has over the API services
      5. The authorization server can be owned by the service provider or general service providers like (google, Facebook, LinkedIn, etc) and the resource server is owned by the service provider.
      6. Scopes are used to restrict the use of API functionalities.
         1. Example: if the account is only authorized to read from the resources it should only read from the service and not write to it.
      7. e.g of an OAuth token : https://piggybank.com/login/oauth/authorize?client-id=****************************scope=transact_hist acct_bal acct_trnsf
      8. Good API documentation should contain all the scopes of an API service and how to utilize them.
      9. OAuth is not an authentication service.
   4. OAuth2 - 4 grant types:
      1. Authorization code(scoped access to a resource server):
         1. authorization code is exchanged for an access token
         2. resource owner credentials remain confidential
         3. The access token is never shared with the resource owner
         4. complex implementation
      2. Implicit(Javascript single page application):
         1. the client is issued an access token directly in the return URL
         2. simple but not secure needs custom security implementations in the client app.
      3. Resource Owner Password Credentials(only used in a high degree of trust environment):
         1. Only a username and password are required
         2. This kind of grant gives the ability to impersonate the resource owner.
         3. use only in emergencies.
      4. Client Credentials(non interactive apps):
         1. authorization scope is limited to protected resources under clients’ control or previously arranged with the authorization server.
         2. only be used for confidential clients or internal clients.
   5. OpenID:
      1. Identity is a set of attributes, one can have many attributes
      2. OpenID compliments OAuth by introducing an identity resource that will authenticate a user.
      3. openID connect provides authorized access to identity.
      4. ID token- acts like an encrypted fingerprint that can be decoded to reveal user information for identity verification
      5. OpenID with OAuth2:
         1. The app makes a request to the authorization server by providing the app name and call back URL, the authorization server returns an ID token and access token to authenticate and authorize the user.
         2. these tokens are then exchanged with the resource server to authenticate and authorize itself.
         3. user info claims - return claims about already authenticated user
   6. JSON Web Tokens (JWT):
      1. compact and self-contained way of securely transmitting information between parties.
      2. A part of javascript object signing and encryption.
      3. JWT token → JWS (Signed JWT for integrity using the private key of the authorization server) → JWE (signed JWT is encrypted for confidentiality using the public key of recipient) → JWK (JWT containing cryptographic keys) → JWA (Defines what algorithm is being used for encryption)
      4. Anatomy of JWT:
         1. header - contains algorithm used to produce signature, key identifiers.
         2. payload - contains a set of claims example issuer of token, came of the subject, and other attributes.
         3. signature - encoding algorithm included in the header.
      5. characteristics of JWT:
         1. claim based:
            1. authorization
            2. authentication
         2. Portability:
            1. stored on client
            2. flexible and extensive
         3. message level encryption
         4. message level signature
         5. media type
         6. limited size
         7. reduce confusion
         8. verbosity and concise
         9. stateful ( token won’t be encrypted) vs stateless (token will be encrypted)
         10. format for refresh, id, and access token.
      6. Challenges:
         1. token revocation
         2. vulnerabilities
         3. performance and overhead
   7. Threat to OAuth2:
      1. Client threat:
         1. obtaining client secrets
         2. obtaining refresh tokens
         3. obtaining access tokens
         4. phishing using a compromised embedded browser
         5. open redirect on client
         6. mitigations:
            1. application access control - cred validation should be performed on server side, implement continuous monitoring and detection and sharing the client id and secret while handshake.
      2. Endpoint Threat:
         1. server impersonation
         2. mitigation - certificate pinning, using out of band certificate validation.
         3. redirection hijack
         4. mitigation - proof key for code exchange
      3. Token threat:
         1. eavesdropping access token
         2. obtaining access tokens from the authorization server database
         3. disclosure of client credentials during transmission
         4. obtaining client secrets from the authorization server database
         5. obtaining client secrets by guessing
         6. Mitigations - token binding

Course Registration:

Click Here

The course is self paced and takes only 4 hours to complete, very easy to understand needs a bit of practice to fully grasp it but is possible if you are fully dedicated.

Feel free to reach out if you need any help

Exam Pattern:

The test is un timed and there are no proctores, the questions are fully focused towards what you have learned throughout the course.