API Security Checklist: Best Practices for REST and GraphQL APIs

An API security checklist turns a vague goal (“make our API secure”) into a concrete, repeatable set of checks you can run before every release. APIs are the most exposed part of most applications today, and the gap between a secure one and a breached one usually comes down to a handful of controls that got skipped because nobody had a list to follow.

This checklist is organized around the OWASP API Security Top 10, the industry-standard framework for what actually goes wrong with APIs. It covers the core controls every API needs, the REST-specific and GraphQL-specific items on top of those, the testing pass that verifies them, and the runtime layer that protects them in production. Work through it section by section, or copy the parts you need into your own engineering wiki.

Table of Contents

• Why You Need an API Security Checklist
• The API Security Checklist (OWASP API Top 10)
• REST API Security Checklist
• GraphQL API Security Checklist
• API Security Testing Checklist
• Runtime API Protection Checklist
• Frequently Asked Questions

Why You Need an API Security Checklist

An API security checklist is valuable because API security fails in predictable ways. The same handful of mistakes (missing object-level authorization, no rate limiting, verbose error messages, forgotten endpoints) show up breach after breach. A checklist makes those mistakes hard to skip, turns tribal knowledge into something a new engineer can follow, and gives every security review a consistent baseline.

The numbers make the case. In Salt Security’s 2025 research, 99% of organizations reported an API security problem in the previous year, and most API attacks now arrive through authenticated, legitimate-looking traffic rather than obvious exploits. In my experience reviewing APIs, the breach almost never comes from an exotic exploit. It comes from one endpoint where the authorization check was assumed instead of written.

The API Security Checklist (OWASP API Top 10)

The OWASP API Security Top 10 (2023 edition) is the most reliable structure for an API security checklist because it reflects what attackers actually exploit. Each item below maps to one risk, with the concrete controls to implement. The full framework lives on the OWASP API Security Project.

API1 — Broken Object Level Authorization (BOLA)

• [ ] Enforce an authorization check on every endpoint that accesses an object by ID
• [ ] Verify server-side, on every request, that the authenticated user may access the requested object
• [ ] Use random, non-sequential IDs (UUIDs) so object IDs cannot be enumerated
• [ ] Never trust the client to send only “its own” IDs

API2 — Broken Authentication

• [ ] Enforce token expiry and rotation; reject expired or tampered tokens
• [ ] Validate JWT signatures with a strong algorithm and never accept alg: none
• [ ] Rate-limit and monitor authentication endpoints to stop credential stuffing
• [ ] Require strong credentials and support MFA for sensitive operations

API3 — Broken Object Property Level Authorization

• [ ] Return only the fields the client needs (no internal flags, hashes, or PII by default)
• [ ] Allowlist which properties a client may set to prevent mass assignment
• [ ] Validate every request against a schema and reject unexpected fields
• [ ] Sanitize and parameterize all input to block injection, including SQL injection and NoSQL injection

API4 — Unrestricted Resource Consumption

• [ ] Enforce rate limiting and throttling per client or API key
• [ ] Cap page sizes, payload sizes, and query complexity
• [ ] Set request timeouts and resource quotas

# Limit each client to 10 requests/second with a small burst (nginx example)limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;location /api/ {    limit_req zone=api burst=20 nodelay;}

API5 — Broken Function Level Authorization

• [ ] Enforce a role check on every administrative or privileged function
• [ ] Deny by default and grant access explicitly
• [ ] Verify roles server-side, never by hiding routes in the UI

API6 — Unrestricted Access to Sensitive Business Flows

• [ ] Identify sensitive flows (signup, checkout, password reset) and add anti-automation
• [ ] Apply bot detection, device fingerprinting, or step-up verification on high-value actions

API7 — Server-Side Request Forgery (SSRF)

• [ ] Validate and allowlist any user-supplied URL the server will fetch
• [ ] Block requests to internal IP ranges and cloud metadata endpoints
• [ ] Disable unnecessary URL schemes and stop following untrusted redirects

API8 — Security Misconfiguration

• [ ] Set security headers and disable verbose error messages
• [ ] Lock CORS down to known origins, never reflect arbitrary ones
• [ ] Disable unused HTTP methods and keep frameworks patched

# Recommended API response security headersStrict-Transport-Security: max-age=63072000; includeSubDomainsX-Content-Type-Options: nosniffContent-Security-Policy: default-src 'none'Cache-Control: no-store# Restrictive CORS: allowlist a known originAccess-Control-Allow-Origin: <https://app.example.com>Access-Control-Allow-Methods: GET, POST

API9 — Improper Inventory Management

• [ ] Keep an up-to-date inventory of every API and version
• [ ] Retire deprecated endpoints and find shadow APIs by reconciling spec against real traffic
• [ ] Document every endpoint in an OpenAPI or GraphQL schema

API10 — Unsafe Consumption of APIs

• [ ] Treat data from third-party APIs as untrusted input and validate it
• [ ] Set timeouts and verify TLS on every outbound call
• [ ] Avoid blindly following redirects from upstream services

For how these API risks relate to the broader application security landscape, see our OWASP Top 10 guide.

REST API Security Checklist

REST APIs share the OWASP controls above and add a few that follow from how REST works over HTTP.

• [ ] Enforce HTTPS everywhere and set HSTS
• [ ] Use correct HTTP methods and return accurate status codes (distinguish 401, 403, and 404)
• [ ] Version the API (for example /v1/) so changes do not break or expose old behavior
• [ ] Validate the Content-Type and reject unexpected media types
• [ ] Never put tokens or sensitive data in URLs or query strings, since they leak into logs
• [ ] Enforce pagination limits on every list endpoint
• [ ] Return consistent, minimal error responses without stack traces

GraphQL API Security Checklist

GraphQL needs its own checklist because its flexibility (one endpoint, client-defined queries) creates risks REST does not have.

• [ ] Disable introspection in production
• [ ] Disable field suggestions (“did you mean”) that leak schema details
• [ ] Enforce a maximum query depth to block deeply nested queries
• [ ] Run query cost or complexity analysis and reject expensive queries
• [ ] Limit or disable query batching and alias-based amplification
• [ ] Apply authorization at the field and resolver level, not just on the endpoint
• [ ] Use persisted (allowlisted) queries for production clients where possible
• [ ] Rate-limit by query cost, not only by request count

API Security Testing Checklist

A checklist of controls is only as good as your verification that they actually work. Run a dedicated testing pass:

• [ ] Scan with an API-aware DAST tool against your OpenAPI or GraphQL schema
• [ ] Fuzz endpoints with malformed and oversized input
• [ ] Manually test BOLA by authenticating as two different users
• [ ] Automate these checks in CI so regressions fail the build

For the full methodology, the best tools, and copy-pasteable examples, see our complete guide to API security testing.

Runtime API Protection Checklist

Runtime API protection monitors live API traffic in production to catch attacks that pre-release controls cannot, such as zero-days and abuse that uses valid stolen credentials. Everything above hardens your API before and during release, but controls drift and most API breaches arrive as legitimate-looking traffic that passes every static check.

• [ ] Monitor production endpoints for anomalous access patterns and abuse
• [ ] Detect injection and exploitation attempts against live traffic, not only in tests
• [ ] Enforce rate limits and detect credential abuse in production
• [ ] Log and alert on authorization failures and unusual data access

Tools like ByteHide App Runtime implement this layer through API Behavior Defense, which works inside the running application to flag injection, credential abuse, and the authorization attacks (like BOLA) that perimeter tools miss, because it sees each request with full application context. It complements an API gateway or WAF rather than replacing it.

Frequently Asked Questions

What is an API security checklist?

An API security checklist is a structured list of security controls to verify on an API before and after release, covering authentication, authorization, input validation, rate limiting, and configuration. Organizing it around the OWASP API Security Top 10 ensures it reflects the risks attackers actually exploit.

What should an API security checklist include?

At minimum: object-level and function-level authorization checks, strong authentication and token handling, input validation and injection prevention, rate limiting and resource caps, restrictive CORS and security headers, an accurate inventory of every endpoint, and validation of data from third-party APIs. REST and GraphQL APIs each add their own items on top.

What is the OWASP API Security Top 10?

It is the industry-standard list of the ten most critical API security risks, published by OWASP, with the current edition from 2023. It includes Broken Object Level Authorization (BOLA), Broken Authentication, and Unrestricted Resource Consumption, and it is the recommended backbone for any API security checklist.

How is a REST API security checklist different from a GraphQL one?

A REST checklist focuses on HTTP methods, status codes, versioning, and per-endpoint controls. A GraphQL checklist adds risks unique to its single flexible endpoint: disabling introspection in production, enforcing query depth and complexity limits, controlling batching, and applying authorization at the field level. The OWASP API Top 10 controls apply to both.

Do you still need runtime protection if you follow the checklist?

Yes. A checklist hardens your API before release, but it cannot catch zero-days or attacks that use valid stolen credentials, which is how most API breaches happen. Runtime protection monitors live traffic and catches what pre-release controls miss, so the two layers work together rather than replacing each other.

Conclusion

A good API security checklist does three things: it maps to the OWASP API Security Top 10 so nothing critical gets skipped, it adapts to REST and GraphQL, and it pairs pre-release controls with runtime protection.

Work through the core OWASP items first, add the REST or GraphQL section that matches your stack, verify everything with a testing pass, and put a runtime layer in front of production. If you want that last layer, ByteHide App Runtime adds runtime API protection that monitors live traffic for injection, abuse, and authorization attacks at the application layer, covering the gaps a checklist alone cannot close.