API abuse: apply request-level policy to direct API traffic
Mobile apps, partner integrations, and backend services may call an API without loading a page. Those requests need a policy built from the evidence the server integration actually receives.
Request a site auditDirect API calls bypass page-level checks
The OWASP API Security Top 10 describes the abuse in three entries: automated access to sensitive business flows such as sign-up, booking, or checkout; unrestricted consumption of compute, storage, or paid third-party calls; and credential attacks against login and recovery endpoints. Each request can be valid on its own. Direct API clients do not run Centinel's browser collector, so they do not provide its browser payload. The server-side decision is limited to the request and session data passed by the integration.
Read the researchWhat the traffic looks like
No page, no JavaScript
A direct HTTP request never executes the page's script, so any check that only runs in the browser never runs at all.
Credentials that leak like passwords
An exposed API key or token can be replayed by a script outside the client or service that was meant to use it.
Traffic shaped like your own app
Legitimate mobile apps, partners, and backend services also use direct requests, so a non-browser client is not automatically abusive.
What runs against this traffic
Use the server request contract
Centinel can evaluate the URL, method, IP address, referrer, headers, and session cookie passed by the integration.
The API policy uses evidence present in its request path without pretending a direct client supplied browser signals.
Read more: Use the server request contractCarry browser evidence into API routes
When a supported browser flow has already run the collector, its session cookie can accompany later requests to protected API routes.
Browser-backed application calls can use the validated session while direct clients remain subject to their own trust policy.
Read more: Carry browser evidence into API routesKeep the API security layer
Centinel does not replace API authentication, authorization, schema validation, or quotas.
Known mobile, partner, and service clients can keep explicit credentials and permissions while Centinel contributes bounded request evidence.
Read more: Keep the API security layerSet policy per route
Policy rules match on URL, method, headers, and client identity, and can apply a rate limit per session or per IP address. A rule in monitor mode logs its decision without enforcing it.
Login, recovery, and expensive search routes can carry stricter limits than cheap reads, and a new rule can be reviewed on real traffic before it blocks a client.
Read more: Set policy per route
Want to see what reaches your site?
Start with a free scraping audit: tested tools, exposed pages, and fixes to consider, reviewed by hand and emailed to you. This checks scraping exposure, not every abuse pattern or all production traffic. Discuss broader workflow coverage in a demo.
API abuse: common questions
What platform and security teams ask before they deploy.
Can Centinel evaluate calls from a mobile app or backend?
Yes, when your server integration sends the request to the validation API. The decision uses the URL, method, IP address, headers, referrer, and cookie it receives. A direct client does not run the browser collector, so keep app authentication in place for the client itself.
Does Centinel replace API authentication or gateway quotas?
No. OWASP notes that API keys are not authentication. Keep authentication, authorization, schema validation, and quotas in the API layer. Centinel adds request evidence and a policy decision in front of it.
How should login and password-recovery endpoints be treated?
OWASP recommends anti-brute-force controls on these endpoints that are stricter than the regular rate limit, and treating recovery like login. A Centinel rule can match those routes and apply its own rate limit per session or per IP address.
How does a partner integration keep access?
Issue the partner a passport. It is a credential for one tool, presented either as a static key in the X-Passport-Key header or as a Web Bot Auth signature under RFC 9421. A policy rule can then allow that passport on the routes the partner needs.
Can we see what a rule would block before enforcing it?
Yes. In monitor mode a matching request is logged with the decision the rule would have made, while the client still receives an allow.
What happens to API traffic if the validator is unavailable?
Platform integrations fail open, so requests continue to your API. For a custom integration, the documentation recommends a 300 to 500 ms client timeout and failing open on server errors and timeouts.