The following checklist (or better yet, checklists) covers the controls that move that score.
Each section maps to a category that Treblle's automated security scoring evaluates. So these checks aren't theoretical; they're what matters (and what's being evaluated) in production.
Work through the list endpoint by endpoint for your highest-risk APIs, then use it as a baseline for any new API that reaches production.
Authentication and authorization checklist
Let's first explain the difference between them:
Authentication - who is making a request (confirmation that you are who you say you are)
Authorization - what you're allowed (and not allowed) to access/do
Both can fail independently, but often fail together. Here's the authentication and authorization checklist:
Every endpoint requires authentication unless there is an explicit, documented reason it shouldn't. Unauthenticated endpoints should be the exception, not the default. Document the business reason for each one.
Authentication is enforced in the implementation, not just declared in the spec. Test every authenticated endpoint with no token, an expired token, and a token with insufficient scope. All three should return 401 or 403, not a 200 with a truncated response.
Tokens are validated server-side on every request. No client-side-only validation. No trusting a field in the request body that claims elevated permissions.
JWTs have short expiry times and a refresh mechanism. Long-lived tokens are a risk amplifier: a leaked token with a 30-day expiry represents 30 days of exposure. Aim for access tokens to be under 15 minutes, with refresh tokens for continuity.
OAuth scopes are narrow and specific. A token scoped to read:users should not be able to write user data. Over-broad scopes mean a compromised token has more access than it needs.
Object-level authorization is checked, not assumed. For every endpoint that returns or modifies a resource identified by an ID (user IDs, account IDs, order IDs), verify that the requesting consumer owns or has permission for that specific resource, not just that they're authenticated. Broken Object Level Authorization (BOLA) is the most common API security vulnerability in production.
Function-level authorization is checked. Admin-only endpoints return a 403 for non-admin tokens, even if the admin endpoint isn't in the public documentation.
Treblle's Authentication Coverage Tracking surfaces which production endpoints are processing unauthenticated requests in practice, not just which endpoints lack an auth declaration in the spec, but which ones are actually seeing unauthenticated production traffic. The gap between those two numbers is the real authentication exposure.
Input validation and injection prevention checklist
Every field in every request is a potential attack vector. Validation and sanitization are the first line of defense.
All inputs are validated against a strict schema before processing. Type, format, length, and allowed values. Reject anything outside those constraints with a 400, not a silent truncation or a database error.
String fields have maximum length limits. Unlimited string inputs are a denial-of-service vector and a potential injection vector. Define and enforce a maximum for every string field.
Numeric inputs have range constraints. An age field that accepts -1 or 999999 is a design gap. Constrain numeric fields to valid ranges.
SQL injection is not possible via any parameter. Use parameterized queries or prepared statements. No query construction by string concatenation using user-supplied values.
XSS payloads in inputs are rejected or sanitized before storage and output. If user-supplied content is rendered in any downstream context (HTML, JSON responses read by browsers), it must be sanitized.
Path traversal attempts are blocked. File paths and filenames from user input must be validated against a whitelist of allowed characters and directories.
Error responses don't leak stack traces, database schema, or internal path information. A 500 error should return a generic message. The stack trace lives in your logging system, not in the HTTP response.
Treblle's Automated Threat Scanning evaluates every request against 20+ threat categories including SQL injection, XSS, and path traversal payloads in real time, providing a continuous runtime check that complements the design-time validation you build into your application.
Rate limiting and throttling checklist
Rate limiting is the primary defence against abuse, brute force, and denial-of-service. It was adopted by only 15% of production APIs in 2025 despite being an OWASP Top 10 control.
Every public-facing endpoint has a rate limit. The limit should reflect the legitimate use case. A search endpoint and an authentication endpoint need different limits.
Authentication endpoints have strict rate limits. Login, password reset, and token refresh are the targets for credential stuffing and brute force. Limits here should be significantly tighter than general API limits (think 10 requests per minute per IP, not 1,000).
Rate limits are applied per consumer, not just per IP. IP-based rate limiting is easily bypassed with distributed requests. Consumer-based limits (keyed on API token or user ID) are more robust for authenticated APIs.
Rate limit headers are returned on every response. X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset - consumers need to know their limit and remaining quota to implement backoff correctly. Returning 429 with no retry guidance is an incomplete implementation.
Bulk and batch endpoints have separate, tighter limits. An endpoint that processes 1,000 records per call has a different abuse profile than one that processes a single record. Limit them accordingly.
Rate limit exhaustion returns 429, not 503 or a silent drop. Consumers need a semantically correct response so they can implement backoff. Returning a server error or silently dropping requests makes client-side error handling impossible.
Transport security checklist
Transport security is the cheapest security control to implement and one of the most commonly misconfigured. 42% of API traffic in 2025 remains unencrypted, which is an increase from 2023 despite rising security investment.
All API traffic is served exclusively over HTTPS. HTTP requests should redirect to HTTPS or be rejected with a 301/308. No mixed-mode serving where some endpoints accept HTTP.
TLS 1.2 is the minimum; TLS 1.3 is preferred. TLS 1.0 and 1.1 are deprecated and should be disabled.
Certificates are valid, not expired, and from a trusted CA. Automated certificate renewal (Let's Encrypt with auto-renewal, or equivalent) eliminates the most common cause of certificate expiry in production.
HSTS is configured with a meaningful max-age. Strict-Transport-Security: max-age=31536000 tells browsers and clients to always use HTTPS for this domain, preventing protocol downgrade attacks.
Certificate pinning is evaluated for high-risk mobile or IoT clients. Not required for all APIs, but worth considering for clients where a MITM attack would have significant consequence.
Mutual TLS (mTLS) is used for service-to-service communication where appropriate. For internal APIs handling sensitive data or high-privilege operations, mTLS provides an additional layer beyond API key or bearer token authentication.
Logging and monitoring checklist
Logging creates the audit trail that makes incident response possible. Monitoring creates the alerting that means you find out about incidents before your consumers do.
Every API request is logged with sufficient context to reconstruct what happened. At minimum: timestamp, endpoint, method, response code, consumer identity, and request duration. For sensitive endpoints: full request and response payload (with PII masked).
Authentication failures are logged and alerted on. A spike in 401 errors is a brute force signal. A single 401 from a known consumer might be a session expiry. The difference matters and requires alerting logic, not just logging.
Logs don't contain sensitive data in plaintext. Passwords, API keys, credit card numbers, and PII should never appear unmasked in logs. Apply masking at the point of capture, not as a post-processing step.
Log retention meets your compliance requirements. GDPR, PCI-DSS, and HIPAA each have specific retention requirements. Make sure your logging infrastructure is configured to retain logs for the required period and to delete them after it.
Anomalous traffic patterns trigger alerts. Unusual request volumes from a single consumer, unexpected geographic origins, repeated failures on the same endpoint; these are signals worth alerting on, not just logging.
Treblle's Sensitive Data Masking detects and strips PII, credentials, and secrets from request and response payloads before storage, so full payload logging is possible without creating a compliance exposure. Detection runs automatically, no manual field-by-field configuration required.
Logging that contains sensitive data is worse than no logging. You lose the privacy protection the data subject is owed, you create a breach surface in your log infrastructure, and you may be storing data in violation of your retention and minimisation obligations. Mask first, store second.
Documentation and spec hygiene checklist
Undocumented APIs are ungovernable APIs. Spec hygiene is a security concern, not just a developer experience one.
Every production endpoint is in the OpenAPI spec.Shadow endpoints receive traffic, but are absent from the spec. They have no documented security requirements, no governance controls, and no deprecation path. Find them and document or decommission them.
Authentication requirements are declared for every endpoint in the spec. The spec is the contract. If an endpoint requires a bearer token, that requirement should be explicit in the spec's security scheme definitions.
Response schemas include error responses, not just success responses. Documenting only 200 responses leaves consumers guessing about error handling. Document at minimum 400, 401, 403, 404, and 500 for every endpoint.
Sensitive endpoints are marked with appropriate metadata. Any endpoint that returns PII, handles financial transactions, or performs privileged operations should carry metadata that makes its sensitivity visible to governance tooling.
The spec is version-controlled and updated with every API change. A spec that was accurate at initial release and hasn't been updated is a documentation liability.
Governance and version management checklist
Governance controls ensure that security standards are applied consistently across the portfolio and maintained over time, not just at the point of initial release.
APIs are versioned from day one. A versioning strategy (/v1/, semantic versioning in headers) makes it possible to deprecate old versions cleanly. 46% of APIs have no formal versioning strategy, which means security patches to the API contract require breaking changes or indefinite backward compatibility.
Deprecated API versions have a published sunset date. Consumers need advance notice. An API version that has been deprecated but is still accessible indefinitely is a security liability. It won't receive the same security attention as the current version.
Security controls are enforced in the CI/CD pipeline, not just documented. Lint rules, spec validation, and contract tests that run on every build catch regressions before they reach production.
Security scores are tracked over time, not just assessed at release. A security review before release tells you the state at one point in time. A continuous score tells you whether the API is getting more or less secure as it evolves.
Treblle's Custom Governance Rules enforce checklist items as automated policy in CI/CD: rules that flag missing authentication declarations, undocumented endpoints, and absent security headers before deployment. Combined with the Security Score, the checklist becomes a living metric rather than a one-time exercise
For the full context, read the API security best practices. This pillar covers the principles behind the controls listed here.
To run these checks automatically across your current API portfolio, Treblle's Security Score evaluates authentication, transport security, and header hygiene continuously from the first connected APIs.
5 ways how Treblle helps with your API security
Security Score. Per-endpoint security grade updated continuously from live production traffic. Evaluates authentication enforcement, HTTPS/TLS status, IDOR exposure, and security header presence.
Authentication Coverage Tracking. Identifies which endpoints are processing unauthenticated requests in production, surfacing the gap between what the spec declares as required and what the implementation actually enforces.
Automated Threat Scanning. Evaluates every request and response against 20+ threat categories in real time, including SQL injection, XSS, and path traversal.
Sensitive Data Masking. Automatically detects and masks PII, credentials, and secrets in request and response payloads before storage. Enables full payload logging without creating a data minimisation risk.
Custom Governance Rules (Spectral). Teams encode checklist items as automated lint rules that run in CI/CD on every spec change. Authentication requirements, security scheme declarations, and response schema completeness checks fire before deployment rather than after a production incident.
A comprehensive API security checklist covers seven areas: authentication and authorisation (every endpoint requires auth, tokens are validated server-side, BOLA is tested), input validation (schema validation, injection prevention, error response hygiene), rate limiting (per-consumer limits on all public endpoints, strict limits on auth endpoints), transport security (HTTPS-only, TLS 1.2+, HSTS), logging and monitoring (full request logging with PII masking, anomaly alerting), documentation (every endpoint in the spec with security requirements declared), and governance (versioning strategy, CI/CD enforcement, continuous score tracking).
What is BOLA in API security?
BOLA stands for Broken Object Level Authorisation. It occurs when an API endpoint returns or modifies a resource identified by an ID without verifying that the requesting consumer has permission for that specific resource. An attacker can enumerate IDs to access records belonging to other users. BOLA is the most common API security vulnerability in production and the top item in the OWASP API Security Top 10.
How often should an API security checklist be reviewed?
The checklist should be run against every new API before production release, against every significant change to an existing API, and on a scheduled basis (at minimum quarterly) for all production APIs. For high-risk APIs continuous automated scoring is more reliable than scheduled manual reviews.
What is the OWASP API Security Top 10?
The OWASP API Security Top 10 is a reference list of the most common and impactful API security vulnerabilities, maintained by the Open Web Application Security Project. The 2023 list covers Broken Object Level Authorisation, Broken Authentication, Broken Object Property Level Authorisation, Unrestricted Resource Consumption, Broken Function Level Authorisation, Unrestricted Access to Sensitive Business Flows, Server-Side Request Forgery, Security Misconfiguration, Improper Inventory Management, and Unsafe Consumption of APIs. Most of the items in this checklist map directly to one or more OWASP categories.
How does automated API security scoring work?
Automated security scoring evaluates API endpoints continuously against a defined set of controls using data from both the API spec and live production traffic. Treblle's Security Score updates in real time as traffic data changes, meaning the score reflects current production behaviour rather than the state at the last scheduled review.
