New · Security testing
API security testing, built from the tests you already have
Generate OWASP-mapped security checks beside your functional REST, SOAP, GraphQL and JSON-RPC tests. BOLA, injection, SSRF, auth and config checks that run in your packs and CI — with findings that lead with what they could not check.
A paid add-on to Professional, Custom and Enterprise licences. Included in the 15-day trial. Who can use it
Why a separate security scan rarely tells the truth
A functional test asks whether your API gives the right answer to a correct request. A security check asks the opposite: when someone sends a request they should not be allowed to send, does your API refuse it?
A scanner that lives apart
A standalone DAST tool keeps its own copy of your endpoints, environments and credentials. It drifts out of step with every release, so the scan tests an API you no longer ship.
A score that hides the fire
One number rolls a critical authorization hole in with a dozen cosmetic header warnings. Nobody can tell from the grade which category is actually on fire.
Unanswerable probes counted as passes
A gateway answers instead of the API, or a probe hits an id that does not exist, and a lazy report quietly scores it green. A clean grade then means nothing.
From functional suite to security coverage in five steps
- 1
Generate
Shift-Left API works through every endpoint and creates security checks as ordinary tests. Running it again refreshes rather than duplicates.
- 2
Add a second user
Add a second authentication profile as a principal. Without one, the checks that find the most serious flaws cannot run.
- 3
Fill the access matrix
Per endpoint, say who should be refused: Deny, Own data only, or Allow for a shared resource. Your answer always wins.
- 4
Run
Run the checks against a test environment you are allowed to test. Intrusive and data-changing checks stay off until allowed.
- 5
Read the findings
Read “What was not checked” first, then the posture in words and each finding with its CVSS, evidence and fix.
What carries over from your functional tests
There is nothing separate to install and no second copy of your endpoints, environments or credentials. Security checks are your own tests, asking the opposite question.
Generated beside your tests
Shift-Left API creates security checks in the same project, as ordinary tests marked with a Security check chip. Nothing separate to install, no second copy of your endpoints.
Your environments and credentials
Checks use the environments and authentication profiles you already have. Without a profile that can sign in, a credentialed check reports itself not evaluated rather than passing.
Real objects, not made-up ids
A by-id probe copies your project’s own passing create test to make a real object, threads its id in, then copies the delete test to remove it afterwards.
They run where your tests run
Security checks live in your packs, so they run on your schedules and from your CI like any other test — including the CI gate with a SARIF file.
Passive checks send nothing extra
Many checks just read responses your other tests already received — a missing header, a cookie without protection, a card number in a body. No extra request is sent.
A fix belongs in the API
A generated security check cannot be edited to accept what it exists to detect. Fix with AI, bulk repair and the assistant all refuse, and say why.
Nine areas, every one mapped to a standard
Each check maps to the OWASP API Security Top 10 (2023), OWASP ASVS and CWE. That mapping is evidence of testing, not a certification. 94 of the 100 checks in the catalogue run today; the six that do not are listed on every report with the reason.
| Area | What it asks |
|---|---|
| Getting in without a credential | Is a request with no credentials refused? A malformed, expired, wrong-issuer or someone-else’s token? A credential in the URL, or over plain HTTP? |
| One user reading another’s data | Is a second test user refused an object they do not own, or one belonging to another tenant? The commonest serious API flaw (BOLA). |
| Fields the caller should not set | Can a role or admin flag be set from the body? Do responses carry secrets — keys, card numbers — or fields the specification never documented? |
| Being overwhelmed | Is an oversized body refused without a server error? Is a burst rate-limited, and can the limit be bypassed by spoofing a forwarding header? |
| Operations the caller should not reach | Does an operation refuse a user marked Deny? Are management paths closed, undocumented methods refused, a destructive MCP tool refused to a lesser user? |
| Configuration | Security headers, cookie attributes, no version number in server headers, TLS version and certificate, plain HTTP refused, CORS not echoing an untrusted origin. |
| Input treated as data | Database quotes, shell characters, path sequences, template expressions — each must be stored or rejected as text, with no database error or stack trace coming back. |
| Requests your API makes | Does a URL field refuse internal destinations? Several are sent — the cloud metadata address, a loopback, a decimal-encoded host — because each defeats a different defence (SSRF). |
| Old and undocumented versions | Are older or undocumented versions of a path still answering? |
A report that leads with what it could not check
“Not evaluated” is not a pass. A gateway answered instead of your API, a probe hit an id that does not exist, a request-forgery probe was accepted and showed nothing — each is reported honestly, first, with the reason. Then the posture in words, and each finding with its CVSS score and vector, the evidence, the standards it fails and how to fix it.
What was not checked, first
Every report opens with what it could not judge and why. A report that quietly counts an unanswerable probe as a pass is worse than no report.
No single score
The posture is the worst open finding, in words — critical weaknesses open, high open, or every check that ran passed. One number would hide which category is on fire.
A finding per endpoint, check and field
A failed check becomes one finding with a severity, a CVSS v3.1 base score and vector, the standards it maps to, the evidence and how to fix it.
CVSS calculated, never guessed
The base score comes from fixed values per check, never from a model, so it pastes straight into a tracker. Shift-Left API’s own adjustments (production raises, no-auth-to-bypass lowers) are shown separately.
Only a person changes a finding
Accepting a risk or marking a false positive needs a reason, kept with the decision. A run never overwrites a decision a person made.
Evidence redacted before it is stored
Credentials, cookies and response bodies are never saved. A leaked card is reported by its last four digits, a private key as “a private key block (not shown)”.
A finding stays yours: only a person can accept a risk or mark a false positive, always with a reason, and a run never overwrites that decision.
The question only a second user can answer
Object-level authorization — OWASP calls it BOLA — is the commonest serious API flaw: one user reading or changing another user’s order or profile just by putting its id in the URL. A scanner with a single identity cannot see it.
Add a second test user as a principal, then fill an access matrix: per endpoint, mark Deny (must be refused), Own data only (may call it, but only on objects it owns) or Allow (a shared resource, never probed). Deny builds the privilege checks; Own data only builds the object-level checks. Where you have not answered, Shift-Left API infers a likely rule, marks it inferred, and any finding resting on it is flagged Suspected — it never infers Deny.
How the checks are generated →
Detects, does not attack
- Shift-Left API detects; it does not attack — benign, inert markers, never a working exploit
- Checks are refused on production unless an Administrator specifically allows them, per environment
- Intrusive checks (request bursts, overloaded bodies) are off until switched on, and never run against production
- Data-changing checks are off until an Administrator allows a specific non-production environment, and never run against production
- Shift-Left API never invents a request, a principal, an id or a body — where it cannot derive a step from a passing test, the check is not built rather than guessed
- AI agents connected through the MCP server can read your posture and findings but cannot start a security run
Gate your build on it
Security checks run inside your packs, so they run wherever your packs run. The headless runner writes a SARIF file for GitHub code scanning or Azure DevOps, and fails the build on severity. --only-new lets a team adopt the gate without first clearing its backlog.
node backend/scripts/run-pack-cli.js \
--pack <packId> --project <projectId> \
--sarif security.sarif \
--fail-on-severity high --only-newExports also include HTML, CSV, JUnit XML and JSON. Ready-made templates ship for GitHub Actions, GitLab, Azure Pipelines, Jenkins and TeamCity.
Paid add-on
API Security Testing add-on
API security testing is a paid add-on to a Professional, Custom or Enterprise licence. No edition includes it on its own, Enterprise included. The 15-day Trial includes it, so you can evaluate it before you buy.
Included in the Trial
A 15-day Trial runs security checks so you can evaluate the whole feature before buying the add-on.
Citizen Developer (Free)
Sees a locked preview with example data. The add-on cannot be bought on the free edition.
If the add-on ends
Findings, runs and reports stay readable. New runs and changes to findings stop until it is renewed; an Administrator is warned 14 days before.
Permissions
Separate permissions to view findings, run checks, manage findings and manage settings. A project you cannot see answers like one that does not exist.
Built-in security testing vs a separate scanner
| Shift-Left API | Separate DAST scanner | |
|---|---|---|
| Where endpoints come from | The functional tests, environments and credentials already in your project | A separate copy of endpoints and auth, maintained in the scanner |
| Authorization flaws (BOLA) | A second principal and an access matrix drive object-level and privilege checks | Often missed — a scanner with one identity cannot ask “is this user refused?” |
| Unanswerable probes | Listed as “not evaluated”, first, never scored as a pass | Frequently counted as a pass, inflating the grade |
| Result | Posture in words plus findings with CVSS, evidence and a fix | A score or a wall of alerts to triage |
| Where it runs | In your packs, schedules and CI gate (SARIF, JUnit), self-hosted or cloud | A separate stage, often cloud-only |
What it deliberately does not do
- It is not a penetration test and no substitute for one. It detects; it does not exploit or chain weaknesses.
- Blind request-forgery confirmation and intrusive amplification are off by default — the first needs a cloud-only collector, the second an Administrator’s allowance.
- It never guesses default passwords or runs working exploits; probes use recognisable but inert markers.
API security testing: frequently asked questions
Is this a penetration test?
No, and it is no substitute for one. Shift-Left API sends benign, inert probes and reads the answers. It does not exploit anything, it does not chain weaknesses together, and it has none of the judgment about your business that a person brings. It is a regression net: it catches the classes of weakness it knows about, every time your tests run.How is this different from a standalone DAST scanner?
Security checks are generated beside the functional tests you already have, in the same project, using the same endpoints, environments and credentials. There is no second copy to drift out of step. Because you can add a second test user and an access matrix, Shift-Left API can ask the question a single-identity scanner cannot — “is this user refused another user’s data?” — which finds the most serious API flaws (BOLA).What does it check, and how much runs today?
94 of the 100 checks in the catalogue run today. They cover getting in without a credential, one user reading another’s data, fields the caller should not set, being overwhelmed, operations the caller should not reach, configuration, input treated as data, server-side request forgery, and old or undocumented versions. The six that do not run are listed on every report with the reason — they are either intrusive bursts that are off until switched on, or need a collector that only the cloud service hosts.Does “no findings” mean my API is secure?
No. It means the checks that ran passed. The checks that could not be judged, and the ones not available at all, are listed on every report and on the CI gate precisely so that sentence is never read as more than it says. Every report opens with “What was not checked”, and a probe that could not reach what it tests is reported “not evaluated”, never as a pass.Which protocols does it cover?
REST, SOAP, GraphQL, JSON-RPC 2.0 / MCP and WebSocket-RPC. The authentication, input and configuration checks apply across all of them; a few are protocol-specific, such as GraphQL introspection, a SOAP operation under the wrong SOAPAction, a destructive MCP tool offered to a lesser user, and a WebSocket type-confusion probe.Which plans include security testing?
API security testing is a paid add-on to a Professional, Custom or Enterprise licence. No edition includes it on its own, Enterprise included. A Trial includes it so it can be evaluated. A Citizen Developer (Free) licence sees a locked preview with example data and cannot buy the add-on. Contact sales for add-on pricing.Can I run security checks from CI/CD?
Yes. Security checks run inside your packs, so they run wherever your packs run. The headless runner can write a SARIF file and fail the build with --fail-on-severity (critical, high, medium or low), and --only-new limits the gate to findings first seen in this run so a team can adopt it without first clearing its backlog. Reports export as HTML, CSV, JUnit XML, SARIF and JSON, and ready-made CI templates ship for GitHub Actions, GitLab, Azure Pipelines, Jenkins and TeamCity.What is stored as evidence?
Evidence is redacted and capped before it is saved. Credentials, cookies and authorization values are never stored, and neither are response bodies. A leaked card number is reported by its last four digits only, and a private key as “a private key block (not shown)”. You set how many days evidence is kept; findings and their history are always kept, because that is how “fixed” and “came back” are known.Does it map to compliance frameworks?
Each check maps to the OWASP API Security Top 10 (2023), ASVS and CWE, and a compliance view rolls those up against PCI DSS 4.0, SOC 2, ISO 27001:2022, NIST SSDF, GDPR and HIPAA. It is evidence of testing, not a certification.
Documentation
Security test your APIs with the tests you already have
The 15-day trial includes API security testing: OWASP-mapped checks, a second-user access matrix and a CI gate, with findings that never count an unanswerable probe as a pass. No credit card required.