Security Guide
The firewall is running. The VPN is configured. Every packet crossing the network boundary is inspected. And yet the breach came through a perfectly formed, authenticated API request. The perimeter model assumes you control the edge. In modern API architectures, there is no edge.
The Model That No Longer Fits
The perimeter model is fifty years old. It assumed infrastructure you owned, users you knew, and traffic that crossed a single boundary. Authenticate at the gate. Trust everything inside.
APIs made that assumption false by design. Every mobile client, partner integration, and third-party webhook talks directly to your business logic — from outside your network, with valid credentials, in a format your server accepts without question. "Inside the network" no longer means trusted. It means nothing.
A WAF inspects HTTP traffic. An IDS watches for anomalous packets. Neither reads your application logic. Neither knows that the user who just sent a valid, authenticated GET request for invoice 1047 owns invoice 42 — not 1047.
APIs Surface Logic, Not Just Data
Web security learned to sanitize inputs and escape outputs. That knowledge matters — but it addresses the wrong layer for most API vulnerabilities. API bugs live in application logic, not in malformed payloads.
The token is valid. The request is well-formed. The user is authenticated. The bug is that your handler returns an object belonging to a different user, or accepts a state change that no business rule should allow. The traffic looks legitimate because, by every network-level measure, it is.
Authenticated as user 42. The request for user 99's order passes every network check.GET /api/orders/8819Authorization: Bearer <valid-token>Content-Type: application/jsonHTTP 200 OK ← firewall passed it. WAF passed it. Authorization logic did not run.
The Attack Surface in Your Route Table
Your route table is your true attack surface. Every path with a parameter is a candidate for object-level authorization bypass. Every mutation endpoint that skips CSRF protection is reachable via cross-site request. Every database call constructed from a string is a potential injection point.
GET /api/users/{id}/documents — whose documents does this return?
PUT /api/accounts/{id}/plan — is the caller permitted to change this plan?
GET /api/export?callback=https://attacker.com — does the server fetch this URL?
DELETE /api/records/{id} — is this deletion logged anywhere?
None of these questions are answered at the network layer. All of them are answered in your source code.
The Same Bug, Every Stack
These vulnerabilities are not language-specific. The pattern appears in every framework and runtime. Object-level authorization bypass in Python looks like this:
Python — FastAPI@app.get("/orders/{id}")async def get_order(id: int, user = Depends(verify_token)):order = db.query(Order).filter(Order.id == id).first()# user.id never compared to order.owner_idreturn order
Node.js — Expressapp.get('/orders/:id', authenticate, async (req, res) => {const order = await Order.findById(req.params.id);// req.user.id never compared to order.ownerIdres.json(order);});
Go — Ginfunc GetOrder(c *gin.Context) {id := c.Param("id")var order Orderdb.First(&order, id)// userID from context never checked against order.OwnerIDc.JSON(200, order)}
Java — Spring Boot@GetMapping("/orders/{id}")@PreAuthorize("isAuthenticated()")public Order getOrder(@PathVariable Long id) {return orderRepository.findById(id).orElseThrow();// @PreAuthorize confirms login, not ownership}
The annotation changes. The ORM changes. The bug is identical: authentication confirms the user is logged in; it says nothing about whether this user may access this object.
Where Runtime Defenses Stop
Runtime defenses work against what they can see. A WAF can block a request containing UNION SELECT. It cannot block a legitimate SQL query that returns another user's data because the query was constructed correctly — it's just authorized incorrectly.
Rate limiting stops brute force. It does not stop an attacker who needs only one request to read one record they shouldn't reach.
Anomaly detection flags unusual traffic. A single authenticated user reading 50 records per minute looks normal. Whether any of those records belong to other users — the detection system doesn't know.
The gap runtime defenses leave is the application logic layer. Static analysis closes it at the source.
What Static Analysis Finds Before Runtime
Object-level authorization bypassData access by ID with no ownership comparison in the handler body. Every route with a parameter is a candidate. The scanner reads the method source, not just the route signature.
Injection via raw queriesSQL queries built by string interpolation or concatenation instead of parameterized inputs. Appears in raw SQL calls regardless of which ORM or database driver you use.
SSRF — user-controlled HTTP destinationsHTTP clients called with URLs constructed from request parameters. A webhook handler that fetches the URL a user supplies is an SSRF path to your internal network.
Weak or missing cryptographyMD5 and SHA-1 used for password hashing. Hardcoded encryption keys. Plaintext password comparison. These patterns are deterministic in source code — no runtime observation needed.
Secrets committed to sourceAWS keys, database credentials, JWT secrets, API tokens. Present in source files, configuration files, and method bodies. 30+ patterns covering every major cloud and service provider.
Security misconfigurationDevelopment exception pages enabled in production. CORS configured to accept any origin. XXE via unrestricted DTD processing. Swagger exposed without an environment guard. Configuration bugs are visible in source before deployment.
Missing audit trail on destructive operationsDELETE endpoints with no logging in the method body. When a destructive action produces no log entry, post-incident investigation starts blind.
End-of-life dependencies and frameworksFramework versions past their support window receive no security patches. The project file declares the version. A scanner reads the project file.
Automated Detection
How ApiPosture Pro Finds These Patterns Before Production
ApiPosture Pro scans your API's source code and endpoint metadata for the eight OWASP API Security categories, secrets in 30+ patterns, and file-level configuration risks. It works on any stack where your API defines routes in source files — your language and framework don't change what the scanner looks for.
›Source code analysis, not just route metadata — the scanner reads method bodies to find what authentication checks run (or don't), what queries get constructed, and what HTTP calls get made.
›File-level scanning — startup configuration, Razor views, project files, and settings files are scanned alongside endpoint code. Misconfiguration lives in configuration, not in route handlers.
›CI/CD integration — run apiposture-pro scan . --fail-on high in your pipeline to block merges that introduce high or critical findings. Works on GitHub Actions, Azure DevOps, GitLab CI, and any runner that executes shell commands.
›Diff mode and trend tracking — compare scans over time to confirm that security work is producing results. The history database is local SQLite; no scan data leaves the machine.
›Confidence scoring — findings are ranked by confidence level so teams know which issues to investigate first and which are lower-signal heuristic flags.
All analysis runs 100% locally. Your source code, your findings, and your history never leave your machine or CI runner. The perimeter model may be obsolete — but your code stays inside it.
