Step 1: Explore the API endpoints
The consumer web platform and the restaurant API are two doors into the same building. You have tested the web door. Now test the API door.
Start with what you discovered during scanning and content discovery. The API authenticates restaurant partners with API keys and serves wholesale pricing, order management, and product data. The endpoint structure follows REST conventions -- resources at predictable paths.
Explore the API endpoints discovered during scanning. Map the authentication model (how API keys are used), the data model (what resources are available), and the endpoint structure. List every endpoint you can identify.
Understanding the API's structure before testing it matters. The web platform has forms and buttons that guide interaction. The API has endpoints and parameters -- nothing guides you except the documentation (if it exists) and what you discover.
Step 2: Test for BOLA
BOLA -- Broken Object Level Authorization -- is the most common API vulnerability, and it is architecturally different from anything you tested on the web platform. SQL injection is an input validation failure: the application doesn't sanitize what you type. BOLA is an authorization architecture flaw: the application authenticates you but doesn't check whether you're allowed to access the specific resource you requested.
The restaurant API has 12 partners, each with their own API key and differentiated pricing. The question: can Partner 1's API key access Partner 3's pricing data?
Test for BOLA on the wholesale pricing endpoints. Use one partner's API key to request another partner's data. Document what data is accessible and what should be restricted.
AI will likely treat this like a web form vulnerability -- trying injection payloads or parameter tampering. The actual test is simpler and more fundamental: substitute one partner's identifier for another and see what comes back. If Partner 1 can read Partner 3's wholesale pricing, that is a direct revenue exposure for Dimitar -- his differentiated pricing strategy is compromised.
Step 3: Test for mass assignment
Mass assignment is another architectural flaw. When an API accepts a JSON body, can the request include fields that should not be user-modifiable? A partner updating their order might include a price field that the API processes without validation -- allowing the partner to set their own wholesale pricing.
Test for mass assignment on API endpoints that accept JSON input. Can you include extra fields (like pricing, role, or permissions) that the API processes without rejecting? Document any fields accepted that shouldn't be.
AI generates form-based exploitation attempts -- HTML form fields, query parameters. API mass assignment works differently: it is about the shape of the JSON body the server accepts. Watch whether AI's approach matches the terrain.
Marcus Webb, a senior penetration tester, asks: "Did you check the mass assignment endpoints?" His question is terse and specific. If you haven't tested mass assignment yet, now you know where to look. If you have, check your evidence -- Marcus asks because this is commonly overlooked.
Step 4: Test JWT handling
If the API uses JSON Web Tokens for any part of its authentication or session management, test the token handling:
Check if the API uses JWTs. If so, test for common JWT vulnerabilities: algorithm confusion, missing signature verification, token expiration bypass. Document your findings.
AI generates JWT tampering exploits from training data that may target vulnerabilities patched years ago. The specific version and configuration of the token library determines what works -- not the theoretical attack surface. Test what AI suggests, but verify against the actual implementation.
Step 5: Write detection rules for API patterns
API attacks look different in logs than web attacks. The endpoints are different (/api/v1/wholesale/pricing vs /search.php). The request structures are different (JSON bodies vs form parameters). The indicators are different (sequential resource ID enumeration vs SQL syntax in query strings).
Write Sigma rules to detect the API exploitation patterns you tested. Focus on BOLA (sequential partner ID access from a single key), mass assignment (unexpected fields in request bodies), and any JWT anomalies. Convert and verify against attack replay.
Open Grafana and compare the log entries from your web exploitation in Unit 5 with the API exploitation logs from this unit. The visual difference matters for detection: rules built for web attacks will not catch API attacks.
Step 6: Contact Dimitar
Dimitar needs a preliminary update. The API handles 40% of his revenue. If partner data is exposed, he needs to know.
Translate the findings into his language. "Your website and your restaurant connection are two different doors into the same building -- and right now someone could walk through the restaurant door and see pricing information meant for other partners." He understands doors and pricing. He does not understand BOLA and authorization architecture.
Send the update through the living client interface.
Dimitar responds with concern about the partner data. Then he asks: "My nephew built a mobile app that connects to the same system. Should that be checked too?"
This is scope creep -- a legitimate concern but a separate assessment. The mobile app is listed in the scope document as out of scope. Flag the connection as a finding in your report (the API may have additional consumers beyond the 12 restaurant partners), but do not expand the assessment boundary. If Dimitar wants the mobile app assessed, that requires a separate scope agreement.
Check: At least one API vulnerability confirmed with evidence of data accessed. Detection rules for API patterns fire on attack replay. Dimitar has received a preliminary update.