Security Guide
The OWASP API Security Top 10 — updated in 2023 — is the field's consensus on where APIs fail. Every item on the list represents a class of vulnerabilities that recurs across codebases, languages, and teams. The question automated scanning answers: which of these does your codebase already contain?
The Detection Spectrum
Not every risk leaves a code-level fingerprint. Some produce patterns a static analyzer identifies in every affected file. Others surface only under specific runtime conditions — traffic volume, user behavior, or business logic paths no tool infers from source alone.
Three categories:
●Reliably detectable — code patterns that exist in source and consistently indicate the vulnerability
●Heuristically detectable — patterns that correlate with the risk but can miss it or flag false positives
●Requires runtime observation — no source-level signal; needs traffic analysis, logs, or active testing
Reliably Detectable by Static Analysis
API1 — Broken Object Level Authorization
BOLA / IDOR — #1 on the list every year it has existed
An endpoint accepts an object identifier from the client and returns that object without verifying the requester owns it. Authentication passes. Authorization never runs.
What static analysis finds: endpoints that accept ID parameters and query the database without visible ownership filtering; unauthenticated endpoints that perform write operations; data access by ID with no user_id filter in the query.
Vulnerable — no ownership checkGET /api/orders/{id}order = db.find(id)return order ← owner never verified
FixedGET /api/orders/{id}order = db.find(id)if order.owner_id != current_user.idreturn 403 Forbiddenreturn order
API2 — Broken Authentication
Missing auth guards, weak token handling, exposed credentials
Endpoints that skip authentication entirely, frameworks that accept unsigned or expired tokens, and password comparison done with string equality instead of a timing-safe hash function.
What static analysis finds: missing authorization decorators on sensitive routes; password == input comparisons instead of hash verification; hardcoded credentials; basic auth usage; JWT configuration that skips signature validation.
API3 — Broken Object Property Level Authorization
Mass assignment and over-posting — accepting more than you should
A client submits an object with a field the API never intended to expose — role, isAdmin, balance. The ORM binds it. The database stores it.
What static analysis finds: model binding that accepts full entity types on write endpoints without explicit property filtering; endpoints that bind directly to database entities rather than dedicated request DTOs.
API7 — Server Side Request Forgery
User-controlled URLs reaching internal infrastructure
The endpoint accepts a URL or hostname from the client and makes an outbound HTTP request with it — reaching internal services, cloud metadata endpoints, or other resources the caller was never meant to access.
What static analysis finds: HTTP client calls — fetch(url), requests.get(url), HttpClient.GetAsync(url), WebClient.DownloadString(url) — where the URL argument traces back to a route parameter, query string, or request body field.
Webhook handlers, URL preview services, and proxy endpoints are the common sources. The fix is an allowlist on the target domain — static analysis catches the missing check.
API8 — Security Misconfiguration
The broadest category — and the richest for automated scanning
Misconfiguration produces discrete, detectable patterns in every framework:
XXE / XML ProcessingXML parsers with DTD processing enabled — DtdProcessing.Parse, FEATURE_DISALLOW_DOCTYPE_DECL: false, libxml2 without entity expansion disabled
Permissive CORSAllowAnyOrigin(), Access-Control-Allow-Origin: *, cors({ origin: true }) — wildcard origins on endpoints that handle credentials
Debug in ProductionDeveloper exception pages, stack trace responses, and debug endpoints not guarded by an environment check — visible in startup configuration and middleware registration
Missing Transport SecurityNo HTTPS redirect, missing HSTS header, HTTP endpoints on services handling authentication or sensitive data
Hardcoded SecretsAPI keys, connection strings, and private keys in source files, config files, or environment defaults — detectable with pattern matching across 30+ secret formats from AWS, Azure, GCP, Stripe, GitHub, and more
Heuristically Detectable — Lower Confidence
API4 — Unrestricted Resource Consumption
Rate limiting, pagination caps, and bulk operation limits
Endpoints with no rate limit, no pagination cap, and no size limit on inputs can be driven into resource exhaustion — crashing the service or running up costs in cloud environments.
What static analysis finds: absence of rate-limiting decorators or middleware calls on high-traffic endpoints; list endpoints with no limit or pageSize parameter; file upload handlers accepting unbounded content. Confidence is lower — limits may be enforced in a gateway or middleware layer not visible at the endpoint itself.
API5 — Broken Function Level Authorization
Admin functions reachable by regular users
Admin, internal, and management endpoints that authenticate the user but don't verify their role. Changing /api/user/settings to /api/admin/settings in a request tool is the standard discovery technique.
What static analysis finds: routes containing admin, internal, or management segments without role-based authorization checks; endpoints that verify authentication but not the role or scope. Heuristic — the role check may live in a policy definition not visible at the handler signature.
API10 — Unsafe Consumption of APIs
Insecure deserialization and blind trust in third-party data
Services that consume third-party APIs and deserialize responses without validation. If the upstream API is compromised or returns unexpected data, blind deserialization lets attacker-controlled content execute code or manipulate application state.
What static analysis finds: TypeNameHandling.Auto / All in JSON settings; BinaryFormatter; pickle.loads(); ObjectInputStream without type filtering — all produce recognizable patterns in source.
Requires Runtime Observation
API6 — Unrestricted Access to Sensitive Business Flows
Correct code, abusive behavior
A valid authenticated user creates a thousand referral codes in a loop, or drains a gift card balance one cent at a time. The code is correct. The authorization is correct. The abuse is behavioral. No static analyzer detects this — it requires rate limiting, bot detection, and anomaly alerting in a runtime layer.
API9 — Improper Inventory Management
APIs you forgot you deployed
Old API versions, undocumented endpoints, and shadow APIs no longer in the registry but still accepting traffic. There is no source-level pattern to detect. Inventory management requires API gateway logs, traffic analysis, and continuous mapping of what is reachable — not readable.
Automated Detection
How ApiPosture Pro Scans for the OWASP API Top 10
The patterns above appear in every API framework. A route that exposes an object ID without an ownership check looks the same whether it's written in C#, Java, Python, or JavaScript:
Python — FastAPI @app.get("/orders/{order_id}") def get_order(order_id: int, user = Depends(get_current_user)): order = db.query(Order).filter(Order.id == order_id).first() # Missing: if order.owner_id != user.id: raise HTTPException(403) return order
Java — Spring Boot @GetMapping("/orders/{id}") public Order getOrder(@PathVariable Long id) { Order order = orderRepo.findById(id).orElseThrow(); // Missing: ownership check against SecurityContextHolder return order; }
Node.js — Express app.get('/orders/:id', authenticate, async (req, res) => { const order = await Order.findById(req.params.id); // Missing: if (order.ownerId !== req.user.id) return res.sendStatus(403) res.json(order); });
ApiPosture Pro maps the seven statically detectable risks to dedicated rules, each backed by deep method body analysis rather than route metadata alone:
›AP101 — BOLA: database access by ID without ownership verification, writes on unauthenticated endpoints, GET endpoints performing destructive operations
›AP102 — Cryptographic failures: weak hashing (MD5/SHA1), hardcoded keys, reversible encryption used for passwords
›AP103 — Injection: SQL via string concatenation in raw queries, insecure deserialization, BinaryFormatter, command injection via process execution
›AP104 — Insecure design: missing CSRF tokens, missing input model validation, bulk operations without limits
›AP105 — Misconfiguration: XXE, permissive CORS, dev middleware in production, missing HTTPS/HSTS, Swagger exposed unconditionally, AllowedHosts wildcard
›AP107 — Authentication failures: missing audit logging on destructive operations, plaintext password comparison, weak session handling
›AP108 — SSRF: outbound HTTP calls with user-supplied URLs, URI construction from route parameters or body fields
›AP201 — Secrets in code: 30+ patterns covering cloud provider keys, database credentials, service tokens, and private keys — scanned across source files and method bodies
All analysis runs 100% locally — your source code never leaves your machine. Add apiposture-pro scan . --fail-on high to your CI/CD pipeline to block merges that introduce these patterns before they reach production.
