Exploit detection

Real applications don't break in one place.

They break where the layers meet. A role that looks correct until you reach it through a workflow. An object that's protected at the endpoint and exposed in the response. A container hardened everywhere except the one path infrastructure forwards. apisec tests all of it, layer by layer, against the running application, and reports what actually executed.

See what's exploitable Request a demo

Every layer, every release, every endpoint.

Six layers, one application

Testing one layer tells you almost nothing.

Most tools pick a layer and live there. Static analysis reads the code. A scanner probes the perimeter. A configuration checker reviews the container. Each returns a clean bill of health for the layer it understands, and the exploit sits in the seam between two of them.

apisec tests down the whole stack, and it tests the transitions. The layers below are not product modules. They are how an attacker works through an application, in the order they work through it.

The exploit lives in the seam. apisec tests the layers and the transitions.

Business Logic

The application doing exactly what it was built to do, for the wrong person.

What gets tested: Workflow and state abuse. Steps executed out of order, skipped approvals, replayed transactions, flows entered from the middle, sequences that were never meant to chain. Scraping, enumeration, and value extraction through legitimate calls.

Why it's hard: Every request is valid. Nothing is malformed. There is no signature to match, because the attack is a sequence, not a payload. This is the layer that generic tooling cannot reach, and it requires knowing how the application is supposed to behave before you can prove it behaved wrongly.

Data Access

Who owns this object, and who just read it.

What gets tested: Object-level authorization, object ownership, predictable and enumerable identifiers, tenant isolation, mass assignment, excessive data exposure, PII in responses, and sensitive fields returned to callers who should never see them.

Why it's hard: Proving a data access failure means holding two identities at once and showing that one reached the other's records. apisec generates owner and attacker roles automatically and runs the comparison, which is the test class teams write by hand and stop maintaining first.

Roles & Permissions

The permission matrix, tested as a matrix.

What gets tested: Role-based and attribute-based access control, function-level authorization, privilege escalation through subtle input changes, unenforced credentials, and endpoints that should require authentication and don't.

Why it's hard: A permission model is combinatorial. Every role against every function against every object. Nobody tests that by hand at any real scale, and a spot check of the important-looking endpoints is exactly how the gap survives.

Application Container

Everything the application runs inside.

What gets tested: Server and application configuration, response and security headers, cookie flags, CORS policy, HTTP methods left open, error handling that leaks stack traces, server and framework detail exposed in headers, and schema drift between what the spec promises and what the application actually does.

Why it's hard: Container issues are individually minor and collectively how an attacker orients. The stack trace names the framework. The header names the version. The permissive CORS policy makes the next step reachable from a browser.

Infrastructure

What the application can be made to reach.

What gets tested: Server-side request forgery through URLs, discovery paths, and exposed internal routes. Internal services reachable from outside. Resource consumption and pagination abuse. Rate limiting and its absence. TLS posture, cipher strength, HSTS, and certificate expiry.

Why it's hard: These findings only matter in context. An SSRF parameter is trivia until you show which internal service it reaches. apisec runs the request and reports what came back.

Security Controls

The classics, aimed rather than sprayed.

What gets tested: Injection across SQL, NoSQL, command, and technology-specific variants. Token and session handling, including JWT algorithm confusion, unsigned tokens, ID tokens misused as access tokens, and OAuth and OIDC replay. Reflected and stored injection. Smart fuzzing across data types, nulls, special characters, and boundary values.

Why it's hard: Not because the attacks are exotic. Because running them well means reaching the endpoint authenticated, with realistic parameters, in the right sequence. Most of the effort in a real injection test is getting to the point where the injection can even be attempted.

Each layer is tested against the Application Model, so every attack is specific to your application rather than drawn from a generic list. Read how the model works →

Where the attacks come from

A security category is a researcher's method, written down once.

A security category is how apisec codifies an attack. Not a signature and not a rule. A method: what an attacker is trying to achieve, the conditions that make it reachable, the sequence to attempt it, and how to tell from the response whether it worked.

The work behind one category is research work. Somebody who breaches applications for a living has to establish the technique, define what proof looks like, decide how it varies across frameworks and databases and auth schemes, and specify the conditions under which it should even be attempted. That is what a category costs. It is also why the library is the asset.

The compounding part: Categories are written once and applied everywhere. When apisec Labs releases a new category, every application already under test inherits it on the next run. No rewriting, no re-onboarding, no per-application maintenance. Your testing program gets deeper without anyone on your team doing anything.

The library is what a decade of offensive research looks like when it stops leaving with the researcher.

One real application

485 endpoints. 80 categories. 71,780 validations.

That is a single application in a single scan. Each validation is a distinct attack, tailored to that endpoint, executed against the live application, and verified by what came back. Not a pattern matched against source code.

The same work by hand means sourcing test data, walking object IDs, forging and re-signing tokens, replaying OAuth flows, and holding two identities in parallel. Months per service, and it goes stale the week after it finishes.

apisec · exploit detectionscan

endpoints under test485

security categories applied~80

validations per scan71,780

re-run cadenceevery release, or nightly

Full coverage of the OWASP API Top 10, mapped category by category, plus a deep library beyond it. Every proven exploit ties back to an OWASP category, a CWE root-cause class, and a CVSS score, so it lands in the frameworks you already report against.

Where the research comes from

We didn't build this library alone.

apisec University has trained more than 100,000 security practitioners in API security, business logic, access control, and AI. Free, structured, and taught by people who do the work. It is the largest community of its kind in this discipline, and it is not a marketing channel. It is where the techniques come from.

That community feeds apisec Labs, our research arm, which publishes original work on exploit validation and turns novel technique into shipped categories. The loop is direct: a researcher establishes a method, Labs codifies it as a category, and every application under test picks it up on the next run.

apisec Labs

Original research on exploit validation, composite application models, and cross-service exploit chains. Published openly.

labs.apisec.ai

apisec University

Free courses, certifications, and hands-on CTF work. 100,000+ practitioners trained.

apisecuniversity.com

The practitioner network

Working offensive security professionals who surface techniques from live engagements, long before those techniques show up in a vendor roadmap.

Attack knowledge has always been a people problem. This is what it looks like when you scale the people instead of the tool.

Reproducibility

Run it twice. Get the same answer.

apisec uses models to reason about your application and to generate attacks. It does not use a model to decide whether an attack worked. Execution is the arbiter. Deterministic, repeatable, replayable, auditable.

Every proven exploit ships as a replayable artifact: the full request sequence, the identity used, the data reached, the blast radius, and the prompt to resolve it. That is what ends the argument with engineering.

Depth in layers, not a longer list.

SAST
DAST
WAS
SCA
Manual pen test

What apisec does

Tests each layer of the application and the transitions between them, using categories built by researchers and aimed by a model of your specific application, then proves the outcome by running it.

What apisec is not

Not a scanner with more signatures. Not a longer findings feed. Volume is not coverage, and a report full of candidates moves the triage cost onto you.

Every layer, every release

The depth of a human. The coverage of a machine.

One expert working across every layer of one application, once a year, was always the best AppSec anyone could buy. apisec runs that same sequence on every application, on every release, and hands you the proof.

See what's exploitable See the Platform →