What is API Security? Beginner Guide (2026)
What Is API Security? Complete Beginner Guide 2026 — BOLA, Broken Auth, SSRF, OWASP API Top 10 Explained With Real Examples
When I first heard the term "API security," I nodded like I understood it. I didn't. I knew what an API was in the same vague way most developers know — it's how apps talk to each other. But what does it mean for an API to be insecure? What exactly goes wrong? And why does it keep causing some of the largest data breaches in history?
It took months of reading, practising on labs, and eventually finding real vulnerabilities to genuinely understand it. This post is my attempt to give you that understanding much faster than it took me to build it.
By the end of this guide you'll understand what APIs are and why they're such attractive targets, you'll know the most common API vulnerabilities with concrete attack examples, and you'll have a practical starting path for learning API security testing yourself.
- What an API actually is — no jargon
- Why APIs are such a big attack target
- OWASP API Security Top 10 — explained simply with real examples
- Real-world impact — what actually happens when APIs get exploited
- Your practical starting path for learning API security
What an API Actually Is — No Jargon
API stands for Application Programming Interface. That name isn't helpful. Here's a picture instead.
When you open Swiggy and search for biryani near you, your app doesn't store all that restaurant data on your phone. It sends a request to Swiggy's servers: "Give me all restaurants serving biryani within 5km of this location." The server responds with a list in JSON format. Your app displays it. That request-response cycle is an API call.
Every time you log into an app, check your bank balance, post on Instagram, or book a cab — your device is making API calls. APIs are the plumbing of the modern internet. They move data between your device and servers, between different services, and between companies' systems.
A typical API request looks like this:
GET /api/v1/restaurants?location=Chennai&cuisine=biryani Host: api.swiggy.com Authorization: Bearer eyJhbGciOiJIUzI1NiJ9... Content-Type: application/json
The server reads this request, verifies who is asking via the Authorization header, runs the query, and responds with JSON data. The Authorization header is the key part from a security perspective — it's what tells the server who you are. When that verification is weak or missing, things go wrong.
Why APIs Are Such a Big Attack Target
APIs are attractive targets for several reasons that compound each other.
First, APIs expose raw application functionality directly. A website might have a login page with a CAPTCHA that slows down automated attacks. The API endpoint behind that same website might accept login requests with no CAPTCHA at all — because when developers added the CAPTCHA to the frontend, they didn't think about the API layer.
Second, APIs often return far more data than the app displays. A common mistake is building an endpoint that fetches a full user object from the database and returns the entire thing — including fields the app never shows the user. The mobile app only displays name and email. But the API response also includes the user's phone number, hashed password, internal account flags, and admin status. The developer never noticed because they were looking at the UI, not the raw API response.
Third, APIs are designed to be called programmatically — which means attackers can automate attacks against them with a short Python script. No browser automation, no clicking, no CAPTCHAs in the way. A simple loop over user IDs or a credential list can test thousands of possibilities per minute.
OWASP API Security Top 10 — Explained Simply
OWASP (Open Web Application Security Project) publishes a dedicated list of the most critical API security vulnerabilities. Here are the most important ones with real attack examples, not just definitions.
1. Broken Object Level Authorization (BOLA)
The API checks whether you're logged in — but not whether you're allowed to access this specific object. You change a number in a URL or request body and get someone else's data.
Attack Example
Your order is at GET /api/orders/10045. You change it to /api/orders/10044. The server returns another user's full order — name, address, items, payment method. The API verified your token. It didn't verify the order belongs to you. This is BOLA — the single most common API vulnerability found in real applications.
What stops it: Every object access must be verified against the authenticated user on the server. Not just "are they logged in?" but "does this order belong to them?"
2. Broken Authentication
Weak token implementation, tokens that never expire, APIs that accept unsigned or tampered JWTs, no rate limiting on login endpoints — anything that makes it easier than it should be to impersonate another user or bypass authentication entirely.
Attack Example
A JWT token has its algorithm set to "alg": "none". Some libraries accept this and skip signature verification entirely. An attacker changes the user ID in the payload to an admin's ID, sets alg to none, removes the signature, and sends the request. They're now authenticated as admin.
What stops it: Always verify JWT signatures. Never accept alg: none. Rate limit login and token refresh endpoints. Set short expiry on access tokens.
3. Broken Object Property Level Authorization
You can update fields you shouldn't be able to. The API accepts extra properties in a request body and applies them to the database object — including privileged fields like is_admin, account_balance, or role.
Attack Example
A profile update endpoint normally accepts {"name": "Amardeep"}. An attacker sends {"name": "Amardeep", "is_admin": true, "credit_balance": 10000}. If the API blindly maps all received properties to the user object (mass assignment), the attacker just gave themselves admin access and ₹10,000 in credit.
What stops it: Use explicit allowlists for which fields each endpoint is permitted to update. Never bind all incoming request properties directly to a database model.
4. Unrestricted Resource Consumption
No rate limits, no request size limits, no complexity limits. An attacker can make millions of requests, upload enormous files, or trigger computationally expensive operations without being slowed down. This can bring down a service or generate enormous cloud infrastructure bills.
What stops it: Rate limiting per user and per IP. Request size limits. Pagination limits. Timeout limits on expensive operations.
5. Broken Function Level Authorization
Regular users can reach admin-only API endpoints. The frontend doesn't show admin buttons — but the API routes still work if you know or guess the URL. Security through obscurity is not access control.
Attack Example
Regular users see /api/profile. The app has an admin panel hidden from the UI. An attacker browses the JavaScript bundle and finds references to /api/admin/users. They send a request to that endpoint with their regular user token. The server responds with a full list of all user accounts, including emails and internal flags — because the route exists and wasn't properly protected.
What stops it: Every endpoint must independently verify the caller's role and permissions server-side. "Admin only" must be enforced in the API handler, not just in the frontend routing.
6. Unrestricted Access to Sensitive Business Flows
An API doesn't properly track or limit sensitive business actions — allowing them to be automated in ways that cause real harm. The API is technically doing what it's supposed to do. The problem is it's doing it at machine speed without limits.
Attack Example
A limited-edition sneaker drops at ₹4,999. An attacker writes a script that calls POST /api/cart/add and POST /api/checkout in rapid succession the moment the sale opens — buying 500 pairs before any real customer completes a purchase. They resell them at inflated prices. The API worked exactly as designed. The business logic was just never defended against automation.
What stops it: Rate limiting on critical business flows. Purchase quantity limits enforced server-side. Behavioural anomaly detection for unusual request patterns.
7. Server-Side Request Forgery (SSRF)
An API accepts a URL as input and fetches that URL from the server side. An attacker supplies an internal address — and the server fetches it, potentially exposing cloud credentials, internal services, or other systems that should never be reachable from the internet.
Attack Example
A "URL preview" feature accepts any URL and returns a thumbnail. An attacker submits http://169.254.169.254/latest/meta-data/iam/security-credentials/ — the AWS instance metadata endpoint. The server fetches it and returns the EC2 role credentials, including AccessKeyId and SecretAccessKey. The attacker now has full AWS access. This is almost exactly what happened in the 2019 Capital One breach — 100 million records compromised via one SSRF vulnerability.
What stops it: Validate all user-supplied URLs against an allowlist. Block requests to private IP ranges (10.0.0.0/8, 169.254.0.0/16, 127.0.0.1). On AWS, use IMDSv2.
8. Security Misconfiguration
Default settings left enabled, unnecessary HTTP methods left open, verbose error messages exposing internal paths or stack traces, CORS configured to accept requests from any origin — all the things that were insecure from the start and never hardened.
What stops it: A hardening checklist for every API deployment. Disable debug mode in production. Configure CORS with explicit allowed origins. Disable HTTP methods (DELETE, PUT) on endpoints that don't need them.
9. Improper Inventory Management
Old API versions left running alongside new ones. Version 1 of an API, supposedly replaced by version 2, still works — and still has all the vulnerabilities that version 2 fixed. Forgotten test environments and staging APIs publicly accessible on the internet.
Attack Example
A company launches /api/v2/users with proper authorization checks, deprecating /api/v1/users. But v1 is never decommissioned. An attacker discovers it via a Google cache of old API documentation. V1 has no rate limiting and returns all user data without ownership checks. The new version is secure. The old one is still live.
What stops it: Full inventory of every API endpoint and version. Formal decommissioning process for old versions. Regular scanning for forgotten endpoints, including in staging and test environments.
10. Unsafe Consumption of APIs
Your application trusts data returned from third-party APIs without validating it. If that third-party API is compromised, returns unexpectedly large data, or sends malicious content, it flows unchecked into your systems.
What stops it: Treat third-party API responses like untrusted user input. Validate data types, sizes, and formats. Never execute or render third-party data without sanitization.
Real-World Impact — What Actually Happens When APIs Get Exploited
API vulnerabilities aren't theoretical. Some of the largest breaches of the past several years were API-related. The pattern is consistent: an endpoint was accessible, didn't properly verify authorisation, and returned or accepted things it shouldn't have.
2019 — Capital One: SSRF via misconfigured WAF → AWS metadata credentials stolen → 100 million customer records exfiltrated.
2021 — Facebook: BOLA in phone number lookup API → 533 million user phone numbers scraped via automated requests.
2023 — T-Mobile: API with no rate limiting → 37 million customer accounts accessed through automated enumeration.
In every case: not a complex zero-day exploit. A basic API vulnerability, automated at scale.
The consequences range from personal data exposure to full account takeover to financial fraud. In healthcare, exposed medical records. In fintech, fund transfers and credit manipulation. In infrastructure, control of physical systems. The severity depends on what data and functionality the API exposes — not on the sophistication of the vulnerability.
Your Practical Starting Path for Learning API Security
API security is highly learnable with free tools and free platforms. Here's a concrete path that works:
- Learn how APIs work first. Use Postman (free) to send requests to public APIs. Understand what JSON looks like, how Authorization headers work, and what the different HTTP methods (GET, POST, PUT, DELETE, PATCH) are for. You can't test what you don't understand.
- Install Burp Suite Community Edition. Configure your browser to proxy through it, then browse any application. Watch every API call appear in Burp's HTTP history. Start modifying parameters and watching how the server responds. This is how most API bugs are found.
- Do PortSwigger Web Security Academy API labs. These are free, well-designed, and specifically built around finding BOLA, broken auth, and other OWASP API Top 10 vulnerabilities in realistic scenarios.
- Set up DVWS (Damn Vulnerable Web Services) locally — a deliberately vulnerable API you can attack with zero legal risk. Practice writing Python scripts against it.
- Read the OWASP API Security Project documentation. The full descriptions of each category include real examples, testing methodology, and prevention guidance written by practitioners.
API Security FAQs
requests library for automation once you're comfortable with manual testing.
Comments
Post a Comment