Ravindra BagaleCourses & study guides Track your progress

Guides

Secure REST APIs with OWASP API Security Top 10

By , Cyber Security trainer LinkedIn Published: Last updated:

OWASP API Security Top 10 is a defender checklist for REST and similar APIs: stop broken object-level authorisation, enforce authentication, limit data exposure and abuse, harden config and business flows, and log what matters — without treating the list as an attack recipe.

Friends! In an app "logged in = safe" is false. API endpoints handle object IDs, tokens, rate limits, and schemas. Today: OWASP API Security Top 10 defence view — high-level risks + blue habits. No exploit PoC. Own lab / written authorisation only.

Quick answer

Secure REST APIs — vertical defender checklist:

  1. Authorise every object access (user A must not read user B’s /orders/{id}).
  2. Authenticate strongly; expire and rotate tokens; never put secrets in URLs.
  3. Return only fields the client needs (mass assignment / excess data out).
  4. Rate-limit and detect abuse (credential stuffing, scraping bursts).
  5. Validate schemas; reject unexpected properties.
  6. Harden admin and debug endpoints; no open Swagger in production without auth.
  7. Log auth failures, authz denials, and admin API use — with owners who wake up.

Tiny mental model:

Client → Gateway (authn / authz / rate / schema) → API → data
Broken object authz = IDOR-class pain
“Works in Postman” ≠ production-safe

What do I need before this guide?

What is the OWASP API Security Top 10 (defence view)?

Secure REST APIs with OWASP API Security Top 10 Client requests hit an API gateway that enforces authn, authz, rate limits and logging before the API and data store. Client App / mobile API gateway Authn + Authz Rate limits Schema checks Audit logs REST API Scoped objects Least data req

Client requests hit an API gateway that enforces authn, authz, rate limits and logging before the REST API and data store.

Names evolve with OWASP editions; the themes defenders keep teaching:

  1. Broken object level authorisation — change an ID, see someone else’s record.
  2. Broken authentication — weak tokens, long-lived secrets, missing MFA on admin APIs.
  3. Broken object property level authorisation — client sets isAdmin=true or reads hidden fields.
  4. Unrestricted resource consumption — no rate / cost limits; one client starves others.
  5. Broken function level authorisation — normal user hits admin-only routes.
  6. Unrestricted access to sensitive business flows — checkout, OTP, password reset abused at scale.
  7. Server-side request forgery (SSRF) themes — API fetches attacker-controlled URLs (high-level).
  8. Security misconfiguration — verbose errors, open CORS, default keys, unused HTTP methods.
  9. Improper inventory management — shadow/old API versions still live.
  10. Unsafe consumption of APIs — trusting third-party API data blindly.

Educational warning: this guide explains what to fix and how to verify on systems you own. It does not walk exploit payloads, bypass chains, or attack scripts.

Real incident: Optus (2022) — API exposure themes

Public reporting on Australia’s Optus 2022 customer-data incident described large-scale exposure tied to API access control / authentication weaknesses in public analyses. Millions of customer records were affected; regulators and boards treated API inventory and authz as board-level topics afterward.

Takeaways (vertical):

  1. What happened — customer PII exposure at national scale with API pathways discussed publicly.
  2. What went wrong (theme) — insufficient gates between the internet and sensitive customer objects.
  3. Care-take — inventory every internet-facing API version (v1 leftovers kill you).
  4. Care-take — object-level authz tests in CI beat “we have a WAF” slides.
  5. Care-take — rate limits and anomaly alerts on bulk export-shaped traffic.
  6. Bonus parallel — Capital One–era cloud lessons: identity + SSRF-class themes still belong in API threat models.

Red Team vs Blue Team (awareness only)

Red Team — what attackers try

  • Swap IDs and roles to reach other tenants’ objects (high-level IDOR theme).
  • Replay or steal long-lived bearer tokens from logs and mobile storage.
  • Abuse unauthenticated “forgot password” / OTP send flows for spam or lockouts.
  • Probe old /v1 hosts that never got the new gateway rules.

Blue Team — defend, detect, respond

  • Deny-by-default authz on every object and admin function.
  • Short-lived tokens; bind sessions to device / risk signals where supported.
  • Schema allow-lists; strip unknown properties server-side.
  • Gateway rate limits + bot / stuffing detections.
  • Central logs of 401/403 spikes and bulk downloads; page humans.

How do I harden a REST API step by step?

Step 1 — Inventory what is live

  1. List public hostnames, versions, and who owns each service.
  2. Mark which routes touch PII, payments, or admin actions.
  3. Kill or lock forgotten staging / docs endpoints.

Step 2 — Fix object and function authorisation

  1. For every GET/PATCH/DELETE /resource/{id}, prove the caller owns that id (or has a role).
  2. Never trust client-supplied user ids for authorisation decisions alone.
  3. Separate “logged in” from “allowed to do this action”.

Step 3 — Tighten authentication

  1. Prefer OAuth2 / OIDC patterns maintained by your platform — not homemade JWT crypto.
  2. Rotate signing keys; set short TTLs; revoke on logout / risk.
  3. MFA for human admin API access; workload identities for services.

Step 4 — Shrink data and schemas

  1. Response DTOs with explicit fields — no dumping ORM entities.
  2. Reject unexpected JSON properties on write.
  3. Paginate list endpoints; cap page size server-side.

Step 5 — Abuse and SSRF-class limits

  1. Per-token and per-IP rate limits on auth and export routes.
  2. If your API fetches URLs, allow-list destinations; block link-local / metadata ranges (follow current cloud guidance).
  3. Cost controls for expensive search / report jobs.

Step 6 — Observe and verify (authorised lab)

  1. In a lab API you own, write automated tests: user A denied on user B’s object.
  2. Confirm 401/403 appear in your logs with request ids.
  3. Load-test only against your lab — never stranger APIs on the public internet.
  4. Document residual risks for the service owner.

Ravindra Bagale's Tip

💡 Students leave Swagger UI public for "documentation clarity". In production, unauthenticated docs = a free attack-surface map. Put auth behind the gateway, keep an inventory sheet. In interviews say: object-level authz + rate limit + schema allow-list. Never forget!

Gateway vs application — who does what?

  1. Gateway / edge — TLS termination, WAF-ish filters, global rate limits, JWT validation, routing.
  2. Application — fine-grained object authz, business rules, field-level filtering, domain logging.
  3. Neither layer alone is enough: a perfect gateway with a blind app still leaks objects; a careful app behind an open debug port still burns.
  4. Put request ids on every response so SOC can join gateway and app logs.
  5. Document which team owns 401 vs 403 vs 429 tuning.

Care-take — API habits that survive audits

  1. One owner per API; quarterly inventory of versions.
  2. Authz unit/integration tests in the pipeline (see DevSecOps guide).
  3. Secrets in a manager — not in mobile apps or git.
  4. CORS allow-lists that match real frontends only.
  5. Break-glass admin routes monitored like root cloud logins.
  6. Tabletop: “bulk /customers export at 3 a.m. IST — who gets paged?”

How do I fix common API security mistakes?

Ghabru naka 😅 — these are the usual ones:

Symptom Likely cause Fix
User sees another user’s order Missing object authz Check ownership / tenant on every id
Token in server access logs Auth header logged raw Redact secrets; shorten TTL
Staging API still on internet Inventory gap Private network or strong auth; decommission
“Works without Auth header” Misconfig / open CORS combo Default deny; gateway policy tests
OTP SMS flood complaints Unbounded business flow Rate limit + CAPTCHA/risk + monitor
Huge JSON dumps to mobile Excess data exposure Explicit response models

Try it at home

On a toy API you control (local Flask/Express or a cloud free tier):

  1. Create two users; prove user A gets HTTP 403 on user B’s resource id.
  2. Add a crude per-IP rate limit on /login; confirm your own lab client eventually gets 429.
  3. List three fields you would never return on a public profile endpoint.
  4. Write one Optus-2022 lesson sentence in your own words.
  5. Do not probe random company APIs — that is not a lab.

Learn it properly

Course lessons:

Related guides: OWASP Top 10 simply · SQL injection prevention · Cloud IAM least privilege · DevSecOps pipeline

Got it? API security = object authz + strong authn + less data + rate limits + inventory + logs. Optus-era lesson: take internet-facing customer APIs seriously. No exploit recipes — tests and gateway policies. Next: learn threat hunting for beginners.

Frequently asked questions

What is the OWASP API Security Top 10?

A community checklist of critical API risks — use it as a defence and testing agenda, not an attack recipe.

What is broken object level authorisation?

When changing an object id lets a caller reach another user’s record — fix with server-side ownership checks.

Are API keys in mobile apps safe?

Treat them as public; put real secrets on the server and use short-lived user tokens.

Is an open Swagger UI OK in production?

Not without authentication — unauthenticated docs map your attack surface for free.

How does Optus 2022 relate?

Public analyses emphasised API access-control weaknesses at scale — inventory and authz tests matter.

Where are deeper lessons on this site?

OWASP Top 10 chapters, IDOR/access-control lessons and IAM done right.