IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
More OWASP API risks — SSRF, misconfiguration & more
The OWASP API Top 10 tour covered missing permission checks and unsafe resource use. Four risks are left, and one more gets a closer look. Your goal: spot business-flow abuse, SSRF, bad setup, forgotten APIs and unsafe trust in other APIs.
- A valid request can still be abuse. Add business limits.
- SSRF: your server fetches a URL the caller chose. Check where it really goes.
- Turn off what the API does not need. Keep errors short.
- Retire old and forgotten APIs. Do not leave them running.
- A reply from another API is outside input. Check it before you use it.
The OWASP API Security Top 10 is a free list of the most common serious API risks, numbered API1 to API10 (2023). Here Maya's pilates-booking API shows API6 to API9, then API10 up close.
API6: every request is valid, and it is still abuse
The studio opens next month's classes every Monday at 9:00. One Monday they fill in two seconds. A script booked every spot with real accounts and correct tokens, then resold the spots, like touts buying every first-day cinema ticket. Every request was legal. The harm came from automating a business flow at a size nobody planned for.
Rate limits alone rarely fix this, because each account stays under them. The defenses start with the business:
- Name the sensitive flows. Buying, booking, signing up, redeeming credits.
- Set business limits. For example, two bookings per customer per release, or a hold that expires. Blocking addresses fails, because the script changes them. MFA fails, because the accounts are real.
- Tell people from scripts. Use device signals and behavior no person shows. See bot detection and CAPTCHA.
API7: server-side request forgery (SSRF)
Many APIs fetch things for the user, such as calendar imports, avatars, link previews and webhooks. SSRF (server-side request forgery) happens when the API fetches a URL the caller chose, without checking where it points. The request then comes from your server, from inside your network, with its access.
an office runner told to "bring the parcel from the address on this slip". The runner wears an office ID card, so the strong-room guard lets them in. If the slip says "strong room", they bring back its papers. The caller wrote the slip. Your server did the walking.
It may reach internal admin panels and databases. In the cloud it may reach the instance metadata service, a special address (169.254.169.254) that can hand out the machine's temporary credentials. Defenses:
- Use an Allowlist for destinations. List the hosts, https only, and the ports allowed. A blocklist is weaker.
- Check the address you will really connect to. A friendly host name can resolve to a private address. Resolve it, refuse private, loopback and link-local addresses, then connect to the address you checked.
- Check every hop of redirects. An allowed server can answer "go look over there" and point back inside.
- Isolate the fetcher. Run it where it has no route to internal services. This holds even if a check has a bug.
API8: security misconfiguration
Right code can still be exposed by how the API was set up. Look for:
- Chatty errors. A stack trace, a SQL query or host names in a reply. Return a short fixed error code. Log details on the server.
- Missing TLS, often on "internal" traffic. Use TLS 1.3, and 1.2 only where you must.
- Features left on. HTTP methods like TRACE, debug endpoints, sample apps, default accounts.
- Private replies with no
Cache-Controlheader. Caches then keep a copy.
The fix is a process: a hardening baseline for every environment, and checks that the running setup matches it.
API9: improper inventory management
You cannot protect an API you do not know is running. The studio's /v2 has limits and strict checks. The old /v1 is "deprecated" but still answers, with neither. A demo host still runs, with a copy of production data. A shadow API runs but nobody documented it. A zombie API is an old version that should be gone but still answers. The fix:
- List every API host, its environment and its versions.
- Keep no production data outside production.
"Deprecated" is a label, not a control. An old version that still answers is usually your weakest part. Retire it and delete its data, or, if it is in real use, protect it equally with the same gateway and rate limits as the current version.
API10: unsafe consumption of APIs
Your API also calls other APIs, such as a partner calendar or a payment provider. Teams often trust those replies more than a user's form. That is a mistake, because a partner's server can be hacked or buggy. Treat a reply like a supplier's delivery note: count the boxes before they go on the shelf.
The studio's partner calendar might send a huge reply, a price of -500, or a field "role": "admin" nobody asked for. Defenses:
- Check each reply against the shape you expect: type, length and range. Keep only the fields you asked for.
- Set limits: a timeout and a maximum reply size.
- Follow redirects only to
httpshosts on your list. - Use TLS to the partner and keep certificate checks on. TLS shows who sent the reply. It does not show the data is safe.
Go deeper: Retiring an old API version
Plan the end of every version: announce it, set a date, then switch it off. Until that date, the old version needs the same protection as the new one. After it, delete the data it held.
Go deeper: More ways to handle other APIs' replies
- Also cap the number of items in a reply.
- Escape partner data before it goes into a query, a page or a command.
- Plan for failure. If the partner is slow or down, fail safe and keep your own API answering.
Go deeper: Business-flow abuse in more detail
A partner that books in bulk should get its own credential and its own limits. Do not mix it with ordinary customers.
OWASP's examples have the same shape. Scalpers buy all limited stock on release day. Someone books most of a plane's seats and cancels them to push the price down. Scripts make fake accounts to farm referral credits. Scripts also check out one second after a page loads, which no person does.
Zara reads the logs from the two-second sell-out. Forty new accounts, all made on Sunday night, from the same kind of device. The fix was a rule of two bookings per release, a human check on accounts younger than a day, and an alert for a release that sells out faster than any person can click.
Go deeper: More SSRF defenses
OWASP describes basic SSRF, where the reply returns to the attacker, and blind SSRF, where nothing returns. Blind SSRF is harder to use, but it can still trigger internal services. In OWASP's example, a webhook feature pointed at the metadata address returns the machine role's credentials (see cloud identity 101).
- Allowlist the destinations, and do not rely on a blocklist. The same place can be written in more than one way.
- Use one well-tested URL parser. Check the value it produces, not the raw string.
- Run the fetcher behind an egress proxy that reaches only the internet.
- Harden the metadata service. Modern ones need a session token first, and refuse requests with proxy headers like
X-Forwarded-For. Turn on the strictest mode. - Give the machine's role only the permissions it needs (least privilege for machines).
The same risk appears when you send webhooks to customer URLs. See signed requests and webhooks.
Go deeper: More signs of misconfiguration
Open CORS is another common setup mistake. See CORS and browser-facing APIs. OWASP also lists unpatched servers and libraries, cloud permissions set too wide, and proxies and servers that read the same request in different ways. It suggests allowing only the HTTP methods and content types each endpoint needs. It also suggests security headers on every reply, and a fixed error format. Browsers keep cookies for sites, so open CORS with cookies is dangerous.
🧪 Interactive lab — enable JavaScript to play with this one.
Read OWASP's SSRF Prevention Cheat Sheet. Then run OWASP crAPI on your own machine. It is a deliberately weak API for learning. Only test systems you own or have written permission to test.