This is curated post from Inon Shkedy Tweets 30 Days of API Security

About Inon Shkedy

API Tip 01

How to use Burp Suite features with APIs:

  1. Stability: Unlike Fiddler and other web proxies, Burp never crashes.
  2. “HTTP History” - view all API Calls since you started the pentest. Some APIs become interesting only after you understand the app.
  3. “Tree view” - understand the API structure & business model behind it
  4. “Intruder” - automate BOLA exploits easily
  5. “Repeater” - save interesting API calls to demonstrate to customer later
  6. After you spent a few hours testing API, You found an AP, but don’t know how to use it? Use “search” -> look for EP name only in responses. Find JS & HTML that use the EP.

API Tip 02

  • Testing a GraphQL API that returns sensitive data?
  • If the query contains a “filter” param, try to send an empty value {“filter”:""}
  • API might return data of other users.

API Tip 03

  • “detailed errors” worst case scenario& why you should always look for them:
    • During pentest (e-commerce), had to find a critical vulnerability as fast as possible.
    • I didn’t find much, so I started sending weird inputs that would trigger errors.
  • Found a feature to renew my VIP membership
  • I changed one JSON property - {“yearStart:“2023”} –> {“yearStart”:“20rr23”} to break syntax
  • API returned a super detailed error (2KB)
  • Apparently, behind the scenes, EP used a legacy internal API
  • External API passed the problematic value to the internal API
  • Problematic value caused a parsing error in the internal API
  • Internal API generated a super long error, including full details of the internal API request
  • Error contained URL of internal API & Authorization header (basic Auth) of internal call
  • I accessed internal API from an American IP address (VPN)
  • Used the user:pass from AuthZ header (base64)
  • Gain FULL access to the management console 😈 From the management console I could edit all store item, and gained full access to the customer base

API Tip 04

  • Many modern B2B apps allow you to change the ownership of objects.
  • These flows tend to be vulnerable to IDOR/BOLA.


  • If a task management platform allows you to assign a task to a different team member flow, try to:
    1. Assign yourself a task that doesn’t belong to your team
    2. Assign your task to a user who’s outside your team

API Tip 05

How to find credentials:

  1. GitHub exposed secrets
  2. Analyze clients’ JS; analyze old JS
  3. Look for JWT tokens, auth tokens
  4. Analyze mobile clients + old versions
  5. Run dictionary attacks + google hacking to find additional JS files
  6. Error traces

API Tip 06

  • - amazing tool.
  • Allows you to create anonymous credit cards with spending limits.


  1. Test business flows involving payments
  2. buy products from unsafe websites

API Tip 07

Hunting for BOLA/IDOR? focus:

  • IDs in Body/Headers
  • Numeric IDs (?id=111)
  • Shared by-design objects (/chats/11/message/21)
  • EPs that receive multiple IDs
  • Old API versions (/v0, /v1, etc)
  • Export features (/report_to_pdf?reprit_id=11)

API Tip 08

  • Smart bug bounty hunter has to understand the business logic of the API.
  • Not all APIs are born equal.
  • Business flow X might be sensitive for company X, but not for company Z.


  • One social network (FB) considers automated comments as spam, while another social network (Twitter) encourages it.

For the former, “captcha bypass” might be an issue, and for the latter not

  1. Understand the business logic of each API you test
  2. Look for sensitive business flows
  3. Read more about “API#6: Unrestricted Access to Sensitive Business Flows”

API Tip 09


  1. ID is GUID? send numeric ID anyway; some APIs support both
  2. Register with an email of an existing user. API might return “user exists” error with ID of the user (map between email & ID)
  3. Repeat #2 with “forgot password” EP

API Tip 10

  • I’ve seen some older websites that use different APIs behind the scenes for different languages.
  • Give it a shot and check if the Spanish version of a website is using different APIs behind the scenes - it might expose other vulnerabilities

API Tip 11

How to find SSRF (no tools):

  1. Use iplogger - simple
  2. Use - catches headers
  3. Susceptible input types:
    • File paths
    • URL
    • Relative paths (any string containing slashed)

API Tip 12

SSRF tip

  • Don’t try / metadata services as a first attempt to exploit SSRF - it’s the most obvious payload.

Easy to detect & block.

  • Input validation might ignore the payload
  • Even worse, WAFs might block you

API Tip 13

  • Webhooks + “test webhook” feature = SSRF on steroids.
  • “Test webhook” functionality often allows you control headers & HTTP structure.
  • Very useful if you want to exploit internal services and management consoles that require special headers

API Tip 14

  • “/api/v1/report-v2” == RED FLAG.
  • If version is mentioned twice/in non-standard parts of URL, it’s possible that the EP was created as a patch a critical security bug, before the engineering team was ready to come up with a new “v2” api.

If you see these API EPs, try to find the original, unpatched versions :

  1. Remove “-v2”
  2. Look for API EPs that are named similarly in:

API Tip 15

  • Always use Burp Suite in background
  • After some traffic is generated
  • Search history for interesting URLs in response bodies of HTML/JS files.


  • /_msearch || _search (elasticsearch)
  • /graphql
  • /admin
  • etc..

Inon Shkedy’s Tweet

API Tip 16

Managed to find credentials of someone else? Always try them in different places!

Real world example:

  • I tested a mobile app of a large coffee shop chain - used apkpure to find an old version w/o Certificate pinning (save time)
  • Interecpted traffic between mobile & API
  • HTTP call had “Auth-legacy” header; removed it - nothing happened
  • Base64 decoded the header’s value
  • found username:password (Basic Auth)
  • Used google hacking to expand attack surface
  • admin
  • found exposed management console
  • used credentials from traffic
  • got full access to admin console, including payment info of all users 😈
  • got free coffee for one year (in the Bay Area)

API Tip 17

Let’s talk about #bots: Always think which business flows might harm the business if used extensively

Eg: purchase an item | verify coupons | upload picture
<The following flow might cause DoS and/or your user to get blocked>

  1. Find API EPs related to the flow.
  2. Generate a legit API call to the EP/s
  3. Send the API call 100 times
  4. If all calls return 200 OK - API is vulnerable to “Unrestricted Access to Sensitive Business Flows”


API Tip 18

Software & devops engineers must keep in mind that some EPs are more sensitive than others.


  • /api/send_verification_code: uses Twilio behind the scenes, company gets charged per use.
  • /resize_image: heavy, slow operation & etc…

Malicious users might use these EPs to increase operational cost/cause DoS.

Learn from OWASP API Project how to find and protect these flows:

API Tip 19

IDOR/BOLA hunting tips: Look for encoded JSON objects in cookies.

Example: %7B%22report_id%22%3A111%7D - they tend be more vulnerable.

Use URL Decoder/Encoder to manipulate the input

API Tip 20

You must understand the business logic of an app in order to find BL vulnerabilities! Methodology:

  1. Run web proxy in background
  2. Before sending any malicious calls, spend 30m-3h (depending on scope) exploring the app as a legit user
  3. Use system as a regular user. Don’t be on auto pilot. Understand why each feature is needed.
  4. Go back to recorded traffic, look for patterns. Understand:
  • API naming
  • common params
  • how ID handled (guid, int, etc)- AuthN, etc
  1. Now it’s time to exploit!

API Tip 21

Understand business logic in order to find BL vulnerabilities!

Look for videos/content explaining how to use tested system:

  • Youtube
  • Reddit
  • Pastebin
  • Twitter
  • PDF files stored under the system domain to find manuals (google hacking)

API Tip 22

Use “bulk import” to bypass input validation.


  • POST /add_contact?name=<script>alert(21)</script>
  • Returns 400? (XSS Blocked 😞 )

Find a feature to upload contacts from file.

  • (POST /import_contact_file) - XSS Bypass 😇😇

API Tip 23

  • Look on Postman Collections ( to find hidden/forgotten APIs of the company you are testing.
  • Use collections as documentation to understand better the business logic of the app (might contain comments, value samples, etc)

API Tip 24

BOPLA/“Excessive Data Exposure” exploitation:

  • After several hours of pentest, use the Burp Suite search to look for PII in response.
  • Also look for business related sensitive data (VIN for vehicle industry, etc)

API Tip 25

Understand AuthN Mechanisms

APIs usually rely on 1 or 2 cookies/headers (aka: Session label) to identify a logged in user.
This value differentiates authenticated from unauthenticated.

How to find:

  1. Find API call returning user info (e.g, GET /user/profile)
  2. Use “Proof by contradiction”:
  3. Duplicate call * number of headers/cookies
  4. Within each call send only one cookie/header till API returns 200 with your info - that’s the session labels.


  • Common session labels:
    • Session ID Cookies
    • Authorization header
    • API Key
  • Cookies starting with “_” can’t be session labels (99% of cases)
  • In some rare cases, session label would be a combination of 2 cookies/headers

API Tip 26


  • Look for IDs in cookies.
  • If you remove cookies (except session ID/AuhtN cookie) from a specific API call, and API returns an error - good chance API fetches something based on cookie value.
  • Might be a potential BOLA/IDOR

API Tip 27

Use “export” to find BOPLA/“Excessive Data Exposure”

Example (facebook):

  • GET /api/friends/212 Returns only public info about friend; But
  • GET /api/export_friend_list?fields=* Returns a file with friends’ PII you are not supposed to access

API Tip 28

Save time by comparing response sizes instead of response bodies.


  • Generate 2 API calls to test for IDOR/BOLA, use 2 different IDs
  • 2 API responses have the same size? EP is probably not vulnerable

Inon Shkedy&rsquo;s Tweet

// Response size are the same - EP isn’t vulnerable to IDOR/BOLA

API Tip 29

  • Different API versions expose different vulnerabilities.
  • Don’t assume that api/v1/ and /api/v2 implement the same security mechanisms.
  • Mechanisms that are often implementad differently across versions:
    • Rate Limiting
    • AuhtN
    • AuthZ

API Tip 30

Feeling stuck but have to find a critical vulnerability?

  1. Wake up early in the morning.
  2. Meditate, do some exercise.
  3. Turn off your phone, disconnect from the world for several hours, drink a coffee.
  4. Dedicate yourself to the process.

Previous Tips

  3. 31 Tips — API Security & Pentesting


  1. Burp Suite - Application Security Testing
  2. GraphQL APIs - Web Security Academy
  3. OWASP API Security Project
  4. Postman
  5. Virtual Cards That Protect Your Payments | Online Payment Security
  6. Traceable: Intelligent API Security at Enterprise Scale