Test your own API for the flaws attackers look for
A website hides a lot behind its buttons, but the API underneath answers anyone who asks it directly, and that is where most modern breaches happen. In this mission you test a REST API for the five flaws that top the OWASP API Security Top 10: broken object-level authorisation (reading another user's data by changing an id), broken authentication (a missing or forged token that still works), excessive data exposure (an endpoint that hands back fields it should hide), missing rate limiting (a login that never slows a password-guesser down), and mass assignment (setting a field like is_admin the app never meant you to touch). You trigger each one for real with curl and httpx against two targets on your own machine: a tiny API you write yourself, deliberately broken so you can see every flaw, and OWASP Juice Shop, the intentionally vulnerable app from course 1. Then you fix every flaw in your own code and prove, with the same requests, that the holes are closed. Every request goes to 127.0.0.1 and nowhere else.
- Course 1, Build a hacking lab, finished, so you can start OWASP Juice Shop at 127.0.0.1:3000 ↗ in Docker. The one legal rule from that lesson applies here in full and never bends
- Helpful but not required: course 2, Web app pentesting with Burp Suite, which introduces login tokens, reading a request and its response, and the idea of changing an id to reach another user's record
- Python 3 with pip, already on most machines (the Level 0 lesson Install anything from GitHub covers the terminal and Python if either is new), plus two small packages, Flask and httpx, that step 2 installs in one line each. No GPU, no paid account
- Windows 11, driven from Windows PowerShell. The steps are nearly identical on macOS and Linux; where a command differs, the fixes note it
The rules, and why APIs leak
Set the one line that keeps this lawful, and learn what an API actually is and why it is the part attackers go for.
This is course 5 of the ethical-hacking track and it keeps the single rule from course 1, Build a hacking lab: you may only test systems you own, or that the owner has given you permission in writing to test. In this mission both targets are yours. One is a tiny API you write yourself and run on your own PC. The other is OWASP Juice Shop, published to be attacked, running in Docker and reachable only from 127.0.0.1. Pointing the very same requests at a real company's API, an app on your phone that talks to someone else's server, or any address that is not your own lab is a computer-misuse offence (in the UK, the Computer Misuse Act 1990), whatever your intention and even if you change nothing.
CarefulEverything in this mission is lawful only because the target is your own. The exact same curl and httpx requests, aimed at an API you do not own or have written permission to test, are a crime. Keep every request pointed at 127.0.0.1, your own API and your own Juice Shop. Never at a live service, a shop, an employer, a friend's app or anyone else's account.Now the ideas. An API (application programming interface) is the set of addresses a program talks to instead of a human. When you open a shop in your browser, the page you see is only the front; behind it the browser quietly calls an API to fetch products, log you in and load your basket. A REST API is the most common style of web API: it speaks plain HTTP (the same GET and POST a browser uses), each thing it manages lives at a tidy address, and it usually hands data back as JSON (labelled, bracketed text). Each of those addresses is an endpoint: one job at one URL, such as
GET /api/users/1to read user 1, orPOST /api/loginto sign in.Here is why APIs are where the breaches happen. The browser page can hide a button, grey out a field or skip a screen, and it feels secure. None of that binds the API. The endpoint answers whoever calls it directly with curl, and every check the web page only implied has to be enforced again, on the server, for each request. When it is not, the data is right there for the asking. Most of this mission is one move: call an endpoint directly and see what it gives up.
One distinction runs through everything below. Function-level authorisation asks "is this caller allowed to use this endpoint at all?" (can an ordinary user reach the admin-only delete route?). Object-level authorisation asks the narrower question "is this caller allowed to touch this particular record?" (user 1 may use the read-a-user endpoint, but may they read user 2?). Confusing the two, or checking the first and forgetting the second, is the single most common API flaw in the world, and it is the first one you will trigger.
The findings in this mission map onto the OWASP API Security Top 10, the industry's reference list of the ways APIs break, published by the Open Worldwide Application Security Project. You will meet five of them by name: API1, broken object-level authorisation (BOLA); API2, broken authentication; API3, broken object property level authorisation, which covers both excessive data exposure and mass assignment; and API4, unrestricted resource consumption, the family that missing rate limiting belongs to. Learning the names matters: it is how you report a flaw and how you look up its fix.
TipA simple habit for the whole lesson: before every request, glance at the address. If it does not start with127.0.0.1, stop. That one check is the whole difference between a lab exercise and an offence.