API security and the OWASP API Top 10, at a glance

Quick answer: API security is the practice of finding and fixing flaws in the API layer that now carries most application traffic. The standard reference is the OWASP API Security Top 10 — 2023 edition (API1:2023 to API10:2023); OWASP has not published a 2026 edition, despite much online content implying otherwise. Broken authorisation dominates: BOLA (API1) is the most common and most damaging risk. To test an API, work through seven steps — (1) discover and inventory endpoints, (2) map authentication and get at least two accounts per role, (3) test object- and function-level authorisation exhaustively, (4) probe object properties for excessive exposure and mass assignment, (5) test injection and SSRF, (6) test resource consumption and business-logic abuse, and (7) report with proven impact. Core tooling is an intercepting proxy (Burp Suite or OWASP ZAP), an API client such as Postman, and enough Python to automate permutation testing.

ID	Risk (OWASP API Security Top 10, 2023 edition)	What goes wrong
API1:2023	Broken Object Level Authorization (BOLA)	API returns or modifies an object by caller-supplied ID without checking entitlement — the most common and most damaging API flaw
API2:2023	Broken Authentication	Weak credentials, missing rate limits on login/OTP, poor token expiry, JWT signature and algorithm mistakes
API3:2023	Broken Object Property Level Authorization	Excessive data exposure in responses, plus mass assignment where clients write fields such as role or isAdmin
API4:2023	Unrestricted Resource Consumption	No rate limits, pagination caps or payload/query limits — causes denial of service and real third-party cost abuse
API5:2023	Broken Function Level Authorization (BFLA)	Standard users reach admin operations by changing HTTP method or path; privileged actions not checked per operation
API6:2023	Unrestricted Access to Sensitive Business Flows	A legitimate business flow automated at a scale the business never intended — invisible to scanners
API7:2023	Server Side Request Forgery (SSRF)	API fetches a caller-supplied URL, letting attackers reach internal services or cloud instance metadata
API8:2023	Security Misconfiguration	Verbose errors, permissive CORS, default credentials, unnecessary methods, debug interfaces left in production
API9:2023	Improper Inventory Management	Shadow and zombie APIs — old unpatched versions and undocumented endpoints nobody owns or tracks
API10:2023	Unsafe Consumption of APIs	Trusting third-party API responses more than user input — compromise upstream, compromise everything downstream

Most modern applications are no longer websites with a database behind them — they are a thin interface sitting on top of dozens of APIs. Your banking app, the food-delivery service, the SaaS dashboard your company runs on and the AI assistant answering your questions are all, underneath, a stream of API calls. That shift has moved the centre of gravity of application security: the attack surface that matters most is now the API layer, not the user interface. Attackers know this, and they increasingly skip the front end entirely and talk to the API directly. This guide is a complete, practical walkthrough of API security in 2026 — what makes APIs different, the real OWASP API Security Top 10, how to actually test an API end to end, how to defend one, and what an API security career looks like in India.

Why APIs are a different security problem

It is tempting to treat API security as a subset of web application security, and the skills do overlap heavily. But APIs fail differently, and understanding why is what separates a tester who finds real issues from one who runs a scanner and reports headers.

There is no user interface to constrain you. A web page decides what buttons you see; an API just exposes endpoints. If the server assumes the client will only ever send valid, well-behaved requests, an attacker who talks to the API directly is under no such obligation. Every constraint that exists only in the front end — a hidden field, a disabled button, a dropdown with three options — effectively does not exist.

Business logic is exposed directly. APIs are, by design, a machine-readable map of what an application can do. Endpoint names, parameter names and object identifiers describe the business model in plain language, which makes it far easier for an attacker to reason about what should be forbidden and then test whether it actually is.

Authorisation is per-object, and easy to get wrong. Most web apps authenticate once and then check permissions at the page level. APIs must check, on every single request, whether this caller may act on that specific object. Miss the check on one endpoint out of four hundred and you have a data breach. This is why broken authorisation dominates the OWASP list below.

APIs multiply and get forgotten. Organisations accumulate old versions, staging endpoints, partner integrations, mobile-only backends and internal services that were never meant to be reachable. This is the shadow-API and zombie-API problem, and you cannot defend an endpoint you do not know exists. In practice, a large share of serious API incidents trace back to an endpoint nobody had on the inventory.

Automation changes the economics. A flaw that requires clicking through a UI is limited by human patience. The same flaw on an API can be scripted to enumerate millions of records in minutes. Scale is what turns a minor authorisation slip into a headline breach.

The OWASP API Security Top 10 — the real, current list

An important accuracy note first. The current edition of the OWASP API Security Top 10 is the 2023 edition, and as of this writing OWASP has not published a 2026 edition. You will find a great deal of content online labelled “OWASP API Top 10 2026” — that is marketing shorthand, not a real OWASP release. The correct citation for each item is API1:2023 through API10:2023, and if you use the wrong edition label in a pentest report or an interview, people who know the standard will notice. Always check the OWASP project page for the current edition before citing it.

API1:2023 — Broken Object Level Authorization (BOLA)

The single most impactful and most common API flaw. The API accepts an object identifier from the caller and returns or modifies that object without verifying the caller is entitled to it. If /api/v1/orders/1024 returns your order and /api/v1/orders/1025 returns somebody else’s, that is BOLA. It is trivially scriptable, which is precisely what makes it so damaging. Testing for it is the highest-value thing you can do on any API engagement.

API2:2023 — Broken Authentication

Weaknesses in how the API establishes who the caller is: guessable or brute-forceable credentials, missing rate limits on login and one-time-password endpoints, weak or absent token expiry, tokens accepted after logout, and — very commonly — JWT handling mistakes such as accepting the none algorithm, failing to verify the signature, or trusting claims the client can modify.

API3:2023 — Broken Object Property Level Authorization

The object-level check passes, but the API exposes or accepts fields it should not. Two halves: excessive data exposure, where the response includes properties the caller should never see because the API returns the whole database record and expects the client to filter; and mass assignment, where the API blindly binds request fields to internal properties, so adding a field such as role or isAdmin to an update request silently escalates privileges.

API4:2023 — Unrestricted Resource Consumption

The API does not bound what a single caller can demand — no rate limiting, no pagination caps, no limits on payload size, query complexity or expensive operations. Consequences range from denial of service to real financial damage where each request triggers a paid third-party service such as SMS, email or an AI model call.

API5:2023 — Broken Function Level Authorization (BFLA)

Authorisation is checked at the object level but not the operation level. A standard user calls an administrative endpoint, or switches the HTTP method from GET to DELETE, and the API complies. Classic tests are swapping methods, walking administrative path prefixes and replaying privileged requests with a low-privilege token.

API6:2023 — Unrestricted Access to Sensitive Business Flows

No single request is malicious, but the API permits a business flow to be automated at a scale the business never intended — bulk-buying limited stock, mass account creation, scraping an entire catalogue, or abusing a referral scheme. This one is invisible to vulnerability scanners because nothing is technically broken; it requires understanding what the business actually cares about.

API7:2023 — Server Side Request Forgery (SSRF)

The API fetches a URL supplied by the caller without adequate validation, letting an attacker make the server issue requests on their behalf — typically to internal services or, in cloud environments, to the instance metadata service to steal credentials. Modern APIs that accept webhooks, image URLs or document links are prime candidates.

API8:2023 — Security Misconfiguration

The broad category: verbose error messages leaking stack traces and internal paths, missing or permissive CORS policies, unnecessary HTTP methods enabled, default credentials, missing transport security, unpatched components and debug interfaces left reachable in production.

API9:2023 — Improper Inventory Management

The shadow- and zombie-API problem formalised. Old versions still live and unpatched, undocumented staging or internal endpoints exposed, and no authoritative record of which APIs exist, what data they handle and who owns them. Attackers routinely find /api/v1/ still running after everyone moved to v3.

API10:2023 — Unsafe Consumption of APIs

Your API trusts data from third-party APIs more than it trusts user input — skipping validation, following redirects blindly or accepting unvalidated responses. Compromise or manipulate the upstream service and you compromise everything downstream of it. This risk grows every year as applications chain more third-party and AI services together; our guide on how MCP servers get hacked covers a very current example of exactly this pattern.

REST, GraphQL, gRPC and SOAP — what changes when you test

The OWASP risks apply across API styles, but the mechanics of finding them differ, and interviewers like asking about this.

REST is the common case: resource-oriented endpoints, HTTP methods carrying meaning, and object identifiers sitting right there in the path. This makes BOLA and BFLA testing straightforward — swap identifiers, swap methods, swap tokens. Start here.

GraphQL collapses the API to a single endpoint with a rich query language, which moves the risk around rather than removing it. Introspection often exposes the entire schema, handing you a map of every type, field and mutation — the first thing to check, and something that should be disabled in production. Authorisation must be enforced per field, not per endpoint, so field-level authorisation gaps are common. Deeply nested or recursive queries create resource-consumption risks that request-count rate limiting does not catch, which is why query depth and complexity limits matter. Batching can also be abused to bypass naive rate limits. Tooling worth knowing includes introspection and query tooling built into Burp Suite, plus community tools for fingerprinting and auditing GraphQL endpoints.

gRPC uses binary Protocol Buffers over HTTP/2, so traffic is not human-readable by default and you generally need the service definition to test effectively — the practical challenge is tooling and proxying rather than novel vulnerability classes. SOAP is older and XML-based, still common in banking and telecom, and brings XML-specific concerns such as external entity processing alongside the usual authorisation problems.

How to actually test an API, step by step

A repeatable methodology beats tool-driven poking. This is the sequence experienced testers follow, and it maps directly onto how a real engagement is scoped and reported.

1. Discovery and inventory

You cannot test what you have not found. Collect documentation — an OpenAPI or Swagger specification, a Postman collection, GraphQL introspection output — and treat it as a starting point rather than the truth, because documentation is always incomplete. Supplement it by proxying the real application and its mobile app through an intercepting proxy to capture endpoints in actual use, decompiling mobile clients for hardcoded base URLs, checking JavaScript bundles for endpoint strings, and probing for older API versions and non-production hostnames. The endpoints missing from the documentation are usually the interesting ones.

2. Map authentication and roles

Understand exactly how the API establishes identity — session cookies, bearer tokens, JWTs, API keys, OAuth 2.0 flows, mutual TLS — and where tokens come from, how long they live and what is inside them. Then get credentials for at least two accounts at each privilege level. This is the single most important piece of engagement preparation, because almost every high-severity API finding is an authorisation finding, and you cannot prove cross-tenant access with only one account.

3. Test authorisation exhaustively — object level and function level

This is where the real bugs are. For every endpoint that takes an identifier, replay the request with account B’s token against account A’s object. Do it for every HTTP method. Then test function-level authorisation by replaying privileged requests with an unprivileged token, changing methods, and walking administrative paths. Be systematic rather than opportunistic — the vulnerable endpoint is rarely the first one you try, and this step benefits enormously from scripting.

4. Probe object properties

Read responses carefully for fields the caller should not receive — internal identifiers, password hashes, other users’ details, flags describing internal state. Then invert it: add unexpected fields to write requests and see whether the API binds them. Send a role, permission, price, status or identifier field that the documented request never included and check whether it takes effect.

5. Injection and input handling

The classics still apply, because an API is just another way to reach the same back end: SQL and NoSQL injection, command injection, template injection, path traversal on file parameters, and SSRF anywhere a URL is accepted. Test the parameters the front end never sends, and try alternative content types and parameter pollution — parsers frequently disagree with each other in exploitable ways.

6. Resource consumption and business logic

Check rate limiting on authentication, one-time-password and expensive endpoints. Check pagination limits, payload size limits and, for GraphQL, query depth and complexity. Then think like the business: which flows would hurt if automated? Try to complete them faster and more often than a human could, and see whether anything stops you.

7. Report with impact

A finding is worth what you can prove. Show the request, the response, the exact privilege boundary crossed and what an attacker could obtain at scale — “any authenticated user can read any other user’s records, demonstrated across N accounts” lands very differently from “BOLA on the orders endpoint.” Clear, reproducible, impact-first reporting is what clients pay for, and it is also what gets junior testers promoted.

The tooling that actually matters

Tools accelerate methodology; they do not replace it. Scanners are genuinely poor at the highest-severity API flaws, because authorisation and business-logic bugs require knowing what should be allowed — context no scanner has.

An intercepting proxy is the core work surface, and Burp Suite is the standard: intercept and replay requests, run automated identifier and method permutations, compare responses across accounts, and work with GraphQL queries directly. If you are new to it, start with our Burp Suite for beginners guide. OWASP ZAP is a capable free alternative. Postman and similar API clients are excellent for organising endpoint collections and scripting multi-step authenticated flows, and they are often how the development team already documents the API — ask for their collection. For discovery, content-discovery tools help find undocumented endpoints and old versions, and template-based scanners are useful for quickly catching known misconfigurations. For GraphQL specifically, introspection tooling and schema-fingerprinting utilities save a great deal of manual work. Our top penetration testing tools guide covers the wider kit.

The most valuable tool, though, is a small amount of scripting. Almost every serious API engagement involves generating a few hundred permutations of a request across two accounts and diffing the responses. Analysts who can write that in Python finish in minutes what others do by hand for hours — which is why scripting appears in every serious job description in this space.

How to defend an API

If you build or run APIs rather than break them, the controls below map directly onto the risks above, and they are ordered roughly by impact per unit of effort.

Enforce authorisation server-side on every request, per object and per function. Derive the caller’s identity from the validated token — never from a client-supplied field — and check entitlement to the specific object before acting. Centralise this so it cannot be forgotten on a new endpoint; the most reliable pattern is one that fails closed by default. Get authentication right: validate tokens properly including algorithm and signature, keep lifetimes short, support revocation, rate-limit and monitor authentication endpoints, and never accept an unverified token.

Control what goes in and out. Define response schemas explicitly rather than serialising whole database records, and allow-list the fields a client may write instead of binding whatever arrives. Validate input against a strict schema. Bound consumption: rate-limit per user and per endpoint, cap page sizes and payloads, and for GraphQL enforce depth and complexity limits, disabling introspection in production.

Know what you have. Maintain a real inventory of every API, its version, its owner and the data it handles; retire old versions deliberately; keep non-production endpoints off the public internet. An API gateway helps enforce consistent authentication, rate limiting and logging, but a gateway is not a substitute for authorisation logic inside the service — it cannot know whether this user owns that order.

Log and detect. Authorisation failures, unusual enumeration patterns and sudden spikes in per-account request volume are exactly the signals a SOC can alert on — and API attacks look very distinctive in logs once you know to look. This is a genuinely under-served detection area; if you work in a SOC, building API-abuse detections is high-value work, and our SOC analyst roadmap covers how to develop that skill set. Design also matters for compliance: under India’s DPDP Act, an API exposing personal data to the wrong caller is a data-protection problem as much as a technical one — treat data minimisation in API responses as a design requirement rather than an afterthought.

Why API security matters more in India in 2026

India runs one of the most API-dense digital economies in the world. Real-time payments, the account-aggregator framework, digital public infrastructure, a very large fintech and SaaS sector, and the near-universal shift to mobile-first services mean an enormous volume of sensitive data moves over APIs every second. Add to that a rapidly growing set of AI-powered products, each of which introduces new API surface between models, tools and data sources, and the exposure compounds — a theme we cover in our guides on AI-powered cyber threats and AI and LLM security certifications.

The regulatory direction reinforces this. India’s DPDP Act places clear obligations around personal data, and CERT-In’s incident-reporting expectations have raised the cost of undetected breaches — and a large share of personal-data exposure incidents are, mechanically, API authorisation failures. Sector regulators in finance and healthcare add further expectations around security testing. The practical consequence for anyone building a career here is that organisations increasingly need people who can test and secure APIs specifically, not just “do a VAPT.” Please treat regulatory points as general context rather than legal advice, and confirm current obligations against official sources for your sector.

API security as a career path, and how to build the skills

API security is not usually a job title on its own — it is a specialisation that makes application security testers, penetration testers and cloud security engineers substantially more valuable, and it is one of the most consistently requested skills in Indian AppSec job descriptions. Roles it feeds directly: application security engineer, penetration tester with a web and API focus, product security engineer, and increasingly cloud and platform security roles where API authorisation and identity are the core problem. See our highest-paying cybersecurity jobs and in-demand cybersecurity skills guides for how this fits the wider market.

The skills to build, in order: solid HTTP and web fundamentals; hands-on proxy work until intercepting and modifying requests is second nature; authentication and authorisation concepts including OAuth 2.0, OpenID Connect and JWT internals; the OWASP API Top 10 with the ability to demonstrate each risk, not just name it; enough scripting to automate permutation testing; and cloud fundamentals, because most APIs now live behind cloud identity and gateway services. Build a deliberately vulnerable API in a lab, exploit each of the ten risks against it, and write up what you did — that portfolio is worth more in an interview than any certificate.

On certification, an honest answer. Macksofy does not currently offer a dedicated API security course, and we would rather say so than sell you something adjacent as if it were the real thing. What we do offer is the training that genuinely covers this ground, because modern web application testing is API testing: OSWA (WEB-200) builds hands-on web and API attack skills and is the most directly relevant programme we run, and OSWE (WEB-300) takes it further into white-box analysis of application and API code. CEH v13 and OSCP provide the broader offensive grounding, CPENT adds breadth across environments, and Security+ or CyberCore are sensible starting points if you are new to security. Since most APIs now sit in cloud environments, Cloud+ and the options in our cloud security certifications guide are a natural complement. On the defensive side, CSA and SOC-200 cover detection and response.

Gaps worth naming. The Burp Suite Certified Practitioner (BSCP) is a well-regarded, genuinely hands-on credential covering web and API testing, and vendor-specific API gateway and cloud platform certifications are valuable if your target employer runs that stack. Macksofy does not offer BSCP or vendor API-gateway training. Pursue those directly through the issuing organisation if you need them. Our web application security certifications guide compares the wider landscape, and if you are planning a full career path rather than a single skill, start with the penetration tester roadmap.

Five mistakes that make API testing shallow

1. Testing with one account. You cannot demonstrate broken object-level authorisation without a second account to prove the boundary was crossed. Ask for two accounts per role before the engagement starts — this is the most common avoidable failure in API testing.

2. Trusting the documentation. The specification describes the API someone intended to build. Undocumented endpoints, old versions and internal routes are where the findings are.

3. Running a scanner and calling it an API test. Automated tools are useful for misconfigurations and known issues, and largely blind to authorisation and business-logic flaws — which is where essentially all the high-severity findings live.

4. Ignoring the mobile app. Mobile clients frequently talk to endpoints the web front end never touches, and are an excellent source of undocumented API surface and occasionally of hardcoded secrets.

5. Reporting without impact. “The endpoint returns extra fields” gets deprioritised. “Any authenticated user can retrieve any customer’s phone number and address, demonstrated at scale” gets fixed this week. Same bug, different report.

Frequently Asked Questions

What is the OWASP API Security Top 10 and which version is current?

It is OWASP’s list of the ten most critical API security risks, used as the standard reference for API testing and reporting. The current edition is the 2023 edition, cited as API1:2023 through API10:2023 — OWASP has not published a 2026 edition, despite a lot of online content implying otherwise. Always check the OWASP project page for the current edition before citing it in a report.

What is BOLA and why is it considered the most serious API risk?

BOLA — Broken Object Level Authorization, API1:2023 — occurs when an API returns or modifies an object based on an identifier supplied by the caller without verifying that the caller is entitled to that object. It is the most serious risk because it is both extremely common and trivially automatable: an attacker who can read one record by changing an identifier can usually script the extraction of every record. It is also invisible to most automated scanners, because only a human knows which user should own which object.

Is API security testing different from web application penetration testing?

They overlap heavily, and in practice most modern web application testing is largely API testing, since the front end is usually just a client. The differences are emphasis and method: API testing has no user interface to constrain input, places far more weight on per-object and per-function authorisation testing across multiple accounts, requires discovering undocumented endpoints and old versions, and depends more on scripting to test at scale.

Which certification should I take for API security in India?

There is no single dominant API-security certification, so the practical route is a strong web application security credential plus a demonstrable portfolio. Macksofy does not offer a dedicated API security course; the most directly relevant training we run is OSWA (WEB-200) for hands-on web and API attack skills and OSWE (WEB-300) for white-box work, with CEH v13, OSCP or CPENT for broader offensive grounding. The Burp Suite Certified Practitioner is another well-regarded hands-on option, which we do not offer and which you would pursue directly through the issuing organisation.

How do I test a GraphQL API for security issues?

Start with introspection — if it is enabled, it hands you the full schema of types, fields and mutations, and it should normally be disabled in production. Then test authorisation at the field level rather than the endpoint level, since a single GraphQL endpoint can expose many operations with different permission requirements. Check for resource-consumption issues using deeply nested or recursive queries, verify that query depth and complexity limits exist, and test whether query batching can bypass rate limiting. Burp Suite has built-in GraphQL support, and community tools exist for fingerprinting and auditing schemas.

What tools do I need to start testing APIs?

An intercepting proxy is the core requirement — Burp Suite is the industry standard and OWASP ZAP is a capable free alternative. Add an API client such as Postman for organising endpoints and scripting authenticated multi-step flows, a content-discovery tool for finding undocumented endpoints and old versions, and enough Python to automate permutation testing across accounts. That scripting ability matters more than any single tool, because the highest-value API tests involve generating and comparing hundreds of request variations.

How do I secure the APIs my company builds?

In priority order: enforce authorisation server-side on every request at both object and function level, deriving identity from the validated token rather than any client-supplied field; validate tokens properly and keep lifetimes short; define explicit response schemas and allow-list writable fields instead of returning or binding whole records; apply rate limits, pagination caps and, for GraphQL, depth and complexity limits; maintain a real inventory so old versions and internal endpoints are not silently exposed; and log authorisation failures and enumeration patterns so your SOC can detect abuse. An API gateway helps with consistency but cannot replace authorisation logic inside the service.

Where to start

If you are new to this, the fastest useful step is practical: set up an intercepting proxy, point a deliberately vulnerable API application at it, and work through the ten OWASP risks one at a time until you can demonstrate each on demand. If you already test web applications, the highest-return change is methodological — get two accounts per role on every engagement and test authorisation systematically rather than opportunistically. That one habit will find more high-severity issues than any tool you add.

Macksofy Trainings runs instructor-led programmes covering the web and API attack skills described here — OSWA (WEB-200) and OSWE (WEB-300) for offensive web and API testing, CEH v13, OSCP and CPENT for broader offensive grounding, and CSA and SOC-200 for the detection side — in classroom and online formats across major Indian cities. See our training locations, and read our guide to the attack techniques defining 2026 for the wider threat picture.

Disclaimer: this guide is for educational and defensive purposes. API security testing must only be performed against systems you own or have explicit written authorisation to assess — unauthorised testing is illegal in India and in most jurisdictions. Regulatory points regarding the DPDP Act, CERT-In and sector requirements are general context, not legal advice; confirm current obligations against official sources. Macksofy Trainings is an EC-Council Accredited Training Center; our CompTIA and Offensive Security programmes (including Security+, Cloud+, CyberCore, OSWA, OSWE, OSCP and SOC-200) are independent exam-preparation bootcamps and are not affiliated with, endorsed by, or certified by CompTIA or OffSec. OWASP is an independent non-profit and this guide is not affiliated with or endorsed by OWASP. All product and certification names are the property of their respective owners.