1. Side Notes
   1. Threat modeling
      1. process used to map out the threats to an API provider.
   2. Threat actor
      1. adversary or attacker of the API.
   3. Token handling
      1. The storage of tokens, the method of transmitting tokens across a network, the presence of hardcoded tokens.
   4. BOLA
      1. Access the information of other accounts, such as payment histories, usernames, email addresses, and account numbers.
   5. BFLA
      1. Transfer money and actually update the account information.
   6. API bug bounties
      1. BugCrowd
      2. Twitter
      3. Apple
      4. Microsoft
      5. Google
      6. Hackerone
2. Information Disclosure
   1. /wp-json/wp/v2/user
3. Broken Object Level Authorization (BOLA)
   1. unauthorized access
   2. GET /api/resource/1 GET /user/account/find?user_id=15 POST /company/account/Apple/balance POST /admin/pwreset/account/90
   3. GET /api/resource/3 GET /user/account/find?user_id=23 POST /company/account/Google/balance POST /admin/pwreset/account/111
4. Broken User Authentication
   1. API keys, tokens, and credentials used in URLs
   2. Rate-limit restrictions when authenticating
   3. Verbose error messaging
5. Excessive Data Exposure
   1. Test the target API endpoints and review the information sent in response.
6. Lack of Resources and Rate Limiting
   1. Send a barrage of requests to the API.
   2. If rate limiting is functioning, you should receive some sort of response informing you that you’re no longer able to make additional requests.
   3. HTTP 429 status code
7. Broken Function Level Authorization (BFLA)
   1. unauthorized actions
   2. When a user of one role or group is able to access the API functionality of another role or group.
   3. Accounts types
      1. administrators
      2. partners
      3. merchants
      4. public users
   4. Functions
      1. altering user accounts
      2. accessing user resources
      3. gaining access to restricted endpoints
8. Mass Assignment
   1. Occurs when an API consumer includes more parameters in their requests than the application intended and the application adds these parameters to code variables or internal objects
   2. guess parameters or fuzz them in API requests
   3. Look for parameters involved in user account properties, critical funcs, administrative actions.
   4. EX
      1. "User": "scuttleph1sh", "Password": "GreatPassword123"
      2. "User": "scuttleph1sh", "Password": "GreatPassword123", "isAdmin": true
9. Injections
   1. SQLI
      1. "Lname": "Hacker", "Address": "' OR 1=0--"
   2. NoSQL injection
   3. System command injection
      1. /api/v1/resources/books?show=/etc/passwd
10. Security Misconfigurations
    1. Includes
       1. verbose error messaging
       2. lack of input sanitization
       3. acceptance of unnecessary HTTP methods
       4. misconfigured headers
       5. misconfigured transit encryption
       6. use of default accounts
11. Improper Assets Management
    1. Exposed APIs that are either retired or still in development.
    2. By paying close attention to outdated API documentation, changelogs, and version history.
    3. older & newer versions
       1. /v1/, /v2/, /v3/
    4. still in development
       1. /alpha/, /beta/, /test/, /uat/, /demo/
    5. Watch for patterns in the API documentation or path-naming scheme, and then make requests based on your assumptions.
12. Business Logic
    1. Statements
       1. Only use feature X to perform function Y.
       2. Do not do X with endpoint Y.
       3. Only admins should perform request X.
    2. EX
       1. 2FA bypass
          1. UserId=hapihacker&password=arealpassword!&MFA=true
          2. UserId=hapihacker&password=arealpassword!&MFA=false