>_ REST API Security Testing Checklist

Short answer

A REST API Security Testing Checklist is a defensive checklist for testing the security of REST APIs before release, production deployment, security review, or regression testing after security fixes.

This checklist is for authorized security testing of REST APIs in development, staging, or approved production-safe environments. It does not replace a penetration test, but it helps QA, developers, and product teams catch common REST API security issues before release.

This checklist does not replace an API Testing Checklist.

API Testing Checklist checks whether an endpoint works correctly:

• status code is correct;
• response schema is valid;
• validation works;
• data is saved correctly;
• invalid request returns the expected error.

REST API Security Testing Checklist checks whether an endpoint can be used unsafely:

• User A cannot access User B’s data;
• regular user cannot perform admin action;
• request body cannot be used to add role: admin;
• API does not expose sensitive data;
• error message does not expose stack trace, SQL details, or secrets;
• CORS is not broader than needed;
• tokens, API keys, and sessions are handled safely;
• rate limits and abuse protection cover sensitive business flows.

The main idea is: REST API security testing answers the question “can this API be abused in a way that breaks access control, data privacy, business logic, or system security?”

---

REST API Security Testing vs API Testing

API Testing checks API contract and functional behavior.

For example:

• GET /orders/{id} returns the correct order;
• POST /users creates a user;
• invalid request returns validation error;
• PATCH /profile updates data;
• response body matches the schema.

REST API Security Testing checks security boundaries.

For example:

• User A cannot access /orders/{userBOrderId};
• regular user cannot call admin endpoint;
• request body cannot modify hidden or protected fields;
• endpoint does not return more data than needed;
• repeated requests cannot abuse a sensitive business flow;
• old API version does not bypass new security checks;
• error response does not expose internal implementation details.

In simple terms:

API Testing: does the endpoint work correctly? REST API Security Testing: can the endpoint be used unsafely?

---

REST API Security Testing vs API Integration Testing

API Integration Testing checks data exchange between systems:

• e-commerce sends order to ERP;
• CRM receives lead;
• payment provider sends webhook;
• retries do not create duplicate records;
• data matches in both systems.

REST API Security Testing checks security properties of the API boundary:

• who can call the endpoint;
• which objects they can access;
• which fields they can read or change;
• which methods are allowed;
• which tokens are accepted;
• which errors are exposed;
• how the API is protected from abuse, excessive requests, and misconfiguration.

An integration can work functionally but still be insecure. For example, CRM sync may successfully create leads, but the API key may have overly broad permissions, or logs may store sensitive payloads.

---

REST API Security Testing vs Penetration Testing

REST API Security Testing Checklist is a practical QA/security checklist for defensive testing before release.

It helps catch common API security issues:

• broken object-level authorization;
• broken function-level authorization;
• mass assignment;
• sensitive data exposure;
• weak token handling;
• unsafe methods;
• weak CORS;
• missing rate limits;
• unsafe error messages;
• exposed deprecated endpoints.

REST API penetration testing is deeper. It is usually performed by a security specialist with an agreed scope, rules of engagement, test environment, reporting process, and remediation follow-up.

This checklist can help prepare for a pentest or support regular security regression, but it does not replace a full penetration test. OWASP API Security Top 10 2023 highlights major API risks such as Broken Object Level Authorization, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Unrestricted Access to Sensitive Business Flows, SSRF, Security Misconfiguration, Improper Inventory Management, and Unsafe Consumption of APIs.

---

Related checklists

Use this guide together with related QA guides when the release touches functionality beyond REST API security:

• API Testing Checklist — for functional API contract testing;
• API Test Cases Checklist — for concrete API test scenarios;
• API Error Handling Testing Checklist — for safe error responses, request IDs, and logs;
• API Smoke Testing Checklist — for quick API checks after deployment;
• API Integration Testing Checklist — for checking data exchange between systems;
• Webhook Testing Checklist — for webhook signatures, duplicate events, retries, and delivery history;
• API Documentation Checklist — for verifying that security behavior is documented;
• Login and Authentication Testing Checklist — for auth, sessions, password reset, roles, and permissions;
• Regression Testing Checklist — for security regression after fixes;
• Payment Testing Checklist — if the REST API is connected to payments, invoices, refunds, or subscriptions.

---

When to use a REST API Security Testing Checklist

Use this checklist when a REST API accepts, returns, or changes data that matters for security, privacy, or business logic.

For example:

• a new REST API is launching;
• a new endpoint is added;
• authentication changes;
• JWT/session/token behavior changes;
• roles or permissions change;
• admin API is added;
• user/account API changes;
• order, payment, invoice, or subscription endpoints change;
• file upload/download is added;
• CORS config changes;
• API key access is added;
• rate limiting changes;
• new API version is published;
• old API versions remain available;
• authorization bug is being fixed;
• there was a production incident related to data access, exposed fields, tokens, CORS, rate limits, or API abuse.

For a small low-risk endpoint, a short security smoke check may be enough. For a public API, partner API, admin API, payment API, multi-tenant SaaS, or APIs with personal data, it is better to go through the full REST API Security Testing Checklist.

---

Short REST API Security Testing Checklist

If you need a quick security smoke check, verify that:

• API is available only through HTTPS;
• authentication is required for protected endpoints;
• request without token is rejected;
• expired or invalid token is rejected;
• User A cannot access User B’s object;
• regular user cannot perform admin action;
• user cannot modify protected fields through request body;
• API does not return unnecessary sensitive data;
• hidden/internal fields are not returned in response;
• unsafe HTTP methods are disabled;
• CORS allows only expected origins;
• rate limits work for sensitive endpoints;
• repeated requests cannot abuse business flow;
• file upload/download endpoints check ownership and file type;
• errors do not expose stack traces, SQL details, secrets, or internal paths;
• logs do not contain passwords, tokens, API keys, or full payment data;
• debug endpoints and test data are not available in production;
• deprecated API versions do not bypass new security checks;
• production-safe security smoke has passed after release.

This is not a pentest. It is a minimal defensive check that helps catch visible REST API security issues before release.

---

REST API Security Testing Checklist

1. Define REST API security scope

Before testing, define which endpoints and risks are in security scope.

Check that:

• REST APIs in scope are known;
• public endpoints are known;
• protected endpoints are known;
• admin-only endpoints are known;
• partner-only endpoints are known;
• internal-only endpoints are known;
• resources with personal data are known;
• resources with financial data are known;
• multi-tenant resources are known;
• endpoints that create/update/delete data are known;
• file endpoints are known;
• endpoints that call external URLs are known;
• endpoints that can be abused are known;
• available API versions are known;
• security decision owner is known.

The main question is: which API endpoints can affect access, private data, money, accounts, roles, business flows, or system integrity?

---

2. Prepare authorized test environment

Security testing should be authorized and safe.

Check that:

• testing is authorized;
• environment is approved;
• production-safe rules are defined if testing production;
• test users are prepared;
• roles are prepared;
• test data is prepared;
• User A and User B are prepared;
• admin user is prepared;
• regular user is prepared;
• tenant/workspace A and B are prepared;
• API keys are prepared;
• tokens are prepared;
• logs and monitoring are available;
• rollback/recovery path is known;
• destructive checks are excluded or approved.

Do not run security testing against production without explicit approval, safe test data, and clear limits.

---

3. Check API inventory and exposed endpoints

Security starts with knowing which APIs are exposed.

Check that:

• API inventory is current;
• documented endpoints match exposed endpoints;
• undocumented public endpoints are absent or intentional;
• old endpoints are not available without reason;
• admin endpoints are not publicly accessible;
• debug endpoints are not available in production;
• test endpoints are not available in production;
• health endpoints do not expose sensitive data;
• staging endpoints are not connected to production data;
• API gateway routing does not expose unnecessary services;
• old API versions are marked and controlled;
• internal endpoints are protected by network/auth controls.

OWASP REST Security Cheat Sheet highlights REST-specific controls such as HTTPS, access control, JWT, API keys, allowed methods, input and content-type validation, management endpoints, error handling, audit logs, and CORS.

---

4. Check HTTPS and transport security

REST API should protect data in transit.

Check that:

• protected API is available only through HTTPS;
• HTTP redirects to HTTPS or is blocked;
• credentials are not sent over HTTP;
• TLS certificate is valid;
• certificate belongs to the correct domain;
• weak or expired certificates are absent;
• production API does not use self-signed certificate;
• HSTS is configured if part of platform policy;
• internal service-to-service calls are protected where required;
• webhooks/callbacks use HTTPS;
• clients do not ignore certificate validation.

Security question: can credentials, tokens, or sensitive payloads be intercepted because of weak transport protection?

---

5. Check authentication

Authentication checks who is calling the API.

Check that:

• protected endpoints require authentication;
• unauthenticated request is rejected;
• invalid token is rejected;
• malformed token is rejected;
• expired token is rejected;
• revoked token is rejected, if supported;
• disabled user cannot authenticate;
• deleted user cannot authenticate;
• wrong credentials are rejected;
• authentication errors are consistent;
• auth endpoint does not leak whether account exists, if required;
• login/session creation is logged safely;
• sensitive credentials are not sent in URL.

Security question: can a caller access protected API without valid authentication?

---

6. Check JWT, session, and token handling

If API uses JWT, session cookies, or bearer tokens, test them separately.

Check that:

• token signature is validated;
• token issuer is validated;
• token audience is validated;
• token expiration is validated;
• token not-before is validated, if used;
• token algorithm is not accepted from untrusted header;
• expired token cannot access resources;
• token after logout is handled according to product rules;
• refresh token flow is safe;
• refresh token rotation works if used;
• session fixation is not possible;
• tokens are not stored in logs;
• tokens are not returned unnecessarily;
• tokens are not accepted from unsafe places.

Security question: can an old, fake, foreign, or improperly validated token be used?

---

7. Check API keys

If API supports API keys, test them as an access boundary.

Check that:

• API key is required for protected key-based endpoints;
• missing API key is rejected;
• invalid API key is rejected;
• revoked API key is rejected;
• API key is scoped to expected access;
• API key is not over-permissioned;
• API key is not exposed in frontend;
• API key is not accepted from URL if policy forbids it;
• API key is not logged;
• API key rate limits are applied;
• API key owner is visible in admin/logs;
• key rotation is supported if needed.

Security question: can a compromised or overly broad API key provide too much access?

---

8. Check object-level authorization / BOLA

Broken Object Level Authorization is one of the most important API security risks.

Check object endpoints:

• User A cannot read User B object;
• User A cannot update User B object;
• User A cannot delete User B object;
• Tenant A cannot access Tenant B resource;
• Workspace A cannot access Workspace B resource;
• order owner is required;
• invoice owner is required;
• file owner is required;
• report owner/role is required;
• direct ID change does not bypass access control;
• authorization is checked on backend, not only UI;
• list endpoints do not expose other users’ objects.

Security question: can a user change an ID in URL or query and access another user’s object?

---

9. Check function-level authorization

Function-level authorization checks who can perform an action.

Check that:

• regular user cannot call admin endpoints;
• viewer cannot perform write actions;
• read-only user cannot create/update/delete;
• manager cannot perform owner-only action;
• external user cannot access internal operation;
• suspended user cannot perform protected action;
• disabled user is blocked;
• unauthorized role receives correct error;
• hidden UI action is still protected at API level;
• direct API call cannot bypass role restrictions.

Security question: can a user call a function that is not available to their UI or role?

---

10. Check object property authorization / mass assignment

Mass assignment happens when API accepts more fields than the user is allowed to change.

Check that:

• user cannot set role through request body;
• user cannot set isAdmin;
• user cannot set accountStatus;
• user cannot set ownerId;
• user cannot set price;
• user cannot set discount;
• user cannot set paymentStatus;
• user cannot set planId beyond allowed flow;
• user cannot modify protected metadata;
• hidden fields are ignored or rejected;
• server uses allowlist of writable fields;
• response does not expose protected fields unnecessarily.

Security question: can a user modify a hidden or protected property by simply adding a field to the request body?

---

11. Check role and permission boundaries

For SaaS, B2B, admin panels, and multi-tenant APIs, roles should be tested systematically.

Check that:

• admin can perform admin actions;
• regular user cannot perform admin actions;
• owner-only actions require owner;
• manager-only actions require manager;
• workspace role is enforced;
• organization role is enforced;
• permission changes take effect;
• downgraded user loses old access;
• invited user has expected access only;
• disabled user loses access;
• service account permissions are limited;
• partner account permissions are limited.

Security question: does actual API access match the product permission model?

---

12. Check sensitive data in responses

API should not return extra data just because frontend does not display it.

Check response bodies for:

• passwords;
• password hashes;
• reset tokens;
• access tokens;
• refresh tokens;
• API keys;
• full payment data;
• full card details;
• internal IDs, if sensitive;
• admin notes;
• private customer data;
• hidden supplier data;
• internal pricing;
• unnecessary PII;
• debug fields;
• stack traces.

Security question: does the API return more data than the client or user role needs?

---

13. Check request body validation

Validation matters for security, not only correctness.

Check that:

• required fields are validated;
• unexpected fields are rejected or ignored safely;
• field length limits are enforced;
• numeric limits are enforced;
• enum values are enforced;
• nested objects are validated;
• array size is limited;
• invalid types are rejected;
• malformed JSON is handled;
• special characters are handled safely;
• validation happens server-side;
• validation error does not expose internals.

Security question: can malformed, oversized, or unexpected body break the API, change protected data, or bypass business rules?

---

14. Check query and path parameter validation

Path and query parameters often control access and filters.

Check that:

• invalid IDs are rejected;
• IDs from another user are rejected;
• IDs from another tenant are rejected;
• negative IDs are handled;
• very large IDs are handled;
• unsupported query parameters are ignored or rejected safely;
• filter values are validated;
• sort values are validated;
• pagination limits are enforced;
• date ranges are validated;
• special characters are handled safely;
• parameter pollution is handled according to rules.

Security question: can a user use path/query parameter to access extra data or trigger unsafe behavior?

---

15. Check content type validation

REST API should accept expected content types and reject others safely.

Check that:

• expected Content-Type is accepted;
• missing content type is handled;
• unexpected content type is rejected;
• response content type is safe;
• JSON endpoints do not accept arbitrary formats unless intended;
• file upload endpoints validate multipart content;
• malformed body does not crash parser;
• content sniffing risks are reduced if part of platform policy;
• errors do not expose parser internals.

Security question: can an unexpected content type bypass validation or trigger unsafe parsing behavior?

---

16. Check HTTP methods

Unnecessary methods should be closed.

Check that:

• only allowed methods work;
• unsupported methods return safe error;
• GET does not change state;
• write methods require auth;
• DELETE is restricted;
• PATCH/PUT are restricted;
• OPTIONS behavior is expected;
• TRACE is disabled if applicable;
• method override cannot be abused;
• method access is checked per role;
• method access is checked per resource.

Security question: can a caller perform an action through an unexpected HTTP method?

---

17. Check CORS

CORS should be as narrow as the product needs.

Check that:

• allowed origins are explicit;
• wildcard origin is not used with credentials;
• production origin is allowed;
• staging origin is not allowed in production unless intentional;
• old domains are removed;
• credentials policy is correct;
• allowed headers are limited;
• allowed methods are limited;
• preflight works for expected clients;
• forbidden origin cannot read response;
• CORS errors are logged if useful;
• mobile/web clients still work.

Security question: can an unauthorized website read API responses through a browser?

---

18. Check rate limits and resource consumption

REST API should protect itself from excessive requests and expensive operations.

Check that:

• login endpoint is rate-limited;
• password reset endpoint is rate-limited;
• signup endpoint is rate-limited;
• search/list endpoints are limited;
• export endpoint is limited;
• file upload is limited;
• expensive filters are limited;
• pagination max limit is enforced;
• request body size is limited;
• array size is limited;
• repeated requests are handled;
• 429 is returned when appropriate;
• normal users are not blocked too aggressively.

Security question: can repeated or expensive API usage consume too many resources or create operational cost?

---

19. Check sensitive business flow abuse

Some flows can be abused even without a technical bug.

Check abuse protection for:

• signup;
• login;
• password reset;
• coupon application;
• referral flow;
• booking reservation;
• ticket purchase;
• checkout;
• invoice generation;
• email/SMS sending;
• trial creation;
• review posting;
• file export;
• report generation.

Security question: can a user automate or repeat a business action in a way that harms the product, cost, or fairness?

---

20. Check SSRF risk

SSRF risk appears when API accepts a URL or remote resource reference and backend makes a request.

Check endpoints that accept:

• image URL;
• webhook URL;
• callback URL;
• import URL;
• file URL;
• avatar URL;
• metadata URL;
• external feed URL;
• integration URL.

Check that:

• URL allowlist is used where possible;
• private/internal network targets are blocked;
• unsafe protocols are rejected;
• redirects are handled safely;
• DNS rebinding risks are considered;
• timeout and size limits are applied;
• response does not expose internal systems;
• errors do not expose internal network details.

Security question: can a user-supplied URL make the server call an internal or unexpected destination?

---

21. Check injection basics

REST API should safely handle input that reaches database, search, logs, templates, commands, or external systems.

Check that:

• input is parameterized in database queries;
• search query is handled safely;
• special characters are handled;
• raw query is not built from user input;
• command execution is not built from user input;
• template fields are escaped where needed;
• log injection is considered;
• JSON injection is handled;
• XML parsing is avoided or hardened if used;
• errors do not expose SQL/query details.

Security question: can user input change the intended query, command, template, or downstream request?

---

22. Check file upload endpoints

File upload endpoints often have elevated security risk.

Check that:

• authentication is required;
• authorization is checked;
• file type is validated;
• file size is limited;
• filename is sanitized;
• path traversal is prevented;
• executable files are blocked if not allowed;
• malware scanning is used if part of policy;
• uploaded file is not publicly accessible unless intended;
• uploaded file is linked to correct user/object;
• metadata is not trusted blindly;
• upload error is safe;
• repeated uploads are rate-limited.

Security question: can file upload lead to unauthorized access, malicious content, storage abuse, or private data exposure?

---

23. Check file download endpoints

Download endpoints should check ownership and permissions.

Check that:

• user can download own file;
• user cannot download another user’s file;
• tenant boundary is enforced;
• signed URLs expire if used;
• deleted file is inaccessible;
• private file is not public;
• filename is safe;
• content type is safe;
• direct object storage URL is protected if needed;
• download is logged if required;
• large downloads are limited if needed.

Security question: can a user change file ID or URL and download another user’s file?

---

24. Check pagination, filtering, and search data leaks

List endpoints often expose data through filters, search, sorting, or pagination.

Check that:

• list returns only user’s allowed objects;
• pagination does not leak other tenant data;
• filters do not bypass ownership;
• search does not return hidden/private records;
• sort field cannot expose internal fields;
• total count does not reveal sensitive information if this matters;
• deleted/draft/private records are excluded;
• admin filters are unavailable to regular user;
• export endpoint follows same authorization;
• cursor cannot be manipulated to access other data.

Security question: can list/search endpoint expose records the user should not see?

---

25. Check error messages

Errors should help debugging without exposing internals.

Check that errors do not contain:

• stack trace;
• SQL query;
• database table names;
• internal service names;
• file paths;
• secrets;
• tokens;
• API keys;
• infrastructure details;
• cloud bucket names;
• excessive object existence information;
• debug variables.

Check that:

• validation errors are helpful but safe;
• auth errors are consistent;
• permission errors do not expose private data;
• server errors are generic to the client;
• detailed error is logged server-side;
• support/debug ID is returned if useful.

Security question: can error response help an attacker understand internal system or confirm existence of private resource?

---

26. Check logs and monitoring

Security testing should check not only prevention, but also visibility.

Check that logs capture:

• authentication failures;
• authorization failures;
• suspicious access attempts;
• repeated invalid requests;
• rate limit events;
• token failures;
• admin actions;
• sensitive object access if required;
• file upload/download if required;
• security-relevant errors;
• correlation/request ID;
• user ID or client ID where safe.

Check that logs do not contain:

• passwords;
• full tokens;
• API keys;
• full card data;
• secrets;
• unnecessary sensitive PII.

Security question: can the team detect and investigate suspicious API behavior without leaking sensitive data in logs?

---

27. Check secrets and debug data

Production API should not expose secrets or debug information.

Check that:

• debug mode is not enabled in production;
• test credentials are not returned in responses;
• secrets are not present in error messages;
• secrets are not written to logs;
• API keys are not present in frontend bundle;
• private config endpoints are not exposed;
• .env or config files are not exposed;
• debug headers do not expose internals;
• staging banners/data are not in production API;
• internal admin fields are not in public response;
• sample/test users are not exposed in production API.

Security question: can API response, logs, headers, or exposed endpoint reveal a secret or internal configuration?

---

28. Check security misconfiguration

Misconfiguration often exposes access even when code itself is correct.

Check that:

• production config is correct;
• staging config is separated;
• debug endpoints are disabled;
• admin endpoints are protected;
• management endpoints are protected;
• test endpoints are disabled;
• CORS is correct;
• allowed methods are correct;
• rate limits are enabled;
• security headers are configured where relevant;
• object storage permissions are correct;
• API gateway routing is correct;
• default credentials are absent;
• unnecessary services are not exposed.

Security question: is the API exposed more broadly than intended because of a configuration mistake?

---

29. Check deprecated API versions

Old API versions can bypass newer security fixes.

Check that:

• all exposed API versions are inventoried;
• deprecated versions are documented;
• old versions still enforce auth;
• old versions still enforce object authorization;
• old versions do not expose old sensitive fields;
• old versions do not accept mass assignment;
• old versions have rate limits;
• retired versions are not accessible;
• clients using old versions are known;
• migration/deprecation plan exists.

Security question: can an attacker use an old API version to bypass newer security controls?

---

30. Check third-party API consumption

A REST API can be insecure not only because of its own input, but also because it trusts external APIs.

Check that:

• third-party response is validated;
• external data is not trusted blindly;
• external errors are handled safely;
• external timeout is handled;
• external webhook signature is verified;
• external IDs are validated;
• external status is mapped safely;
• unexpected fields are ignored safely;
• external payload does not overwrite protected fields;
• external service compromise is considered in risk model.

Security question: can unsafe third-party response affect internal data, status, permissions, or business flow?

---

31. Check payment API security, if applicable

If REST API is connected to payments, invoices, refunds, or subscriptions, check that:

• user cannot change payment amount;
• user cannot mark order as paid;
• user cannot create refund without permission;
• user cannot access another user’s invoice;
• payment status comes from trusted source;
• duplicate webhook is safe;
• refund status authorization is enforced;
• full card data is never returned;
• payment provider secrets are not logged;
• idempotency is used for critical payment actions;
• failed/pending/paid states are handled safely.

Security question: can user manipulate money-related API behavior or see another customer’s financial data?

---

32. Check admin and management endpoints

Admin APIs need separate security checks.

Check that:

• admin endpoints require admin auth;
• regular user cannot access admin endpoints;
• internal-only admin API is not public;
• admin actions are logged;
• destructive actions are protected;
• role changes are protected;
• user suspension is protected;
• billing/admin operations are protected;
• admin data export is protected;
• admin search does not leak data to non-admin;
• management endpoints are not exposed publicly.

Security question: can a non-admin call administrative or management action?

---

33. Check security regression after fixes

After a security fix, check not only the original bug but also similar cases.

Check that:

• original issue is fixed;
• affected endpoint is retested;
• similar endpoints are checked;
• User A/User B access is retested;
• role boundaries are retested;
• old API version is checked;
• mobile/frontend behavior still works;
• no new functional regression appears;
• logs show blocked attempt;
• automated regression is added if possible.

Security question: was only one symptom fixed, or the whole class of issue?

---

34. Run production-safe security smoke

After release, run safe production smoke if approved.

Check only non-destructive scenarios:

• unauthenticated protected request is rejected;
• invalid token is rejected;
• regular user cannot access admin endpoint;
• user cannot access another user’s safe test object;
• CORS is expected;
• HTTPS is expected;
• old retired endpoint is unavailable;
• no debug/test endpoint is exposed;
• no staging data is present in production API;
• logs/monitoring show blocked attempts safely.

Production security smoke should be approved, limited, and safe. Its goal is to confirm that obvious security controls did not break after deployment.

---

35. Document REST API security testing result

Security testing should end with a clear result.

Document:

• environment;
• API version;
• endpoints tested;
• roles tested;
• users/tenants tested;
• security areas covered;
• issues found;
• severity;
• reproduction steps;
• evidence;
• affected data/risk;
• fixed/not fixed status;
• remaining risks;
• regression recommendation;
• pass/fail decision.

Security bug report should be precise, but it should not expose secrets, real customer data, or dangerous payloads to a broad audience.

---

Common mistakes

1. Testing only happy-path API behavior

Endpoint can return correct data for the right user and still be insecure for the wrong user.

2. Not testing object-level authorization

Changing object IDs is one of the most important REST API security checks. User A should not access User B’s resources.

3. Trusting the UI to enforce permissions

If a button is hidden in UI, the API still must enforce permissions server-side.

4. Not testing mass assignment

If request body accepts hidden fields, users may change roles, prices, statuses, owners, or permissions.

5. Returning too much data

Frontend may ignore sensitive fields, but attackers can read raw API responses.

6. Ignoring old API versions

Deprecated endpoints can preserve old security bugs long after the current API is fixed.

7. Not checking CORS

Overly broad CORS can expose API responses to unauthorized browser origins.

8. Not checking rate limits and business flow abuse

Some API abuse does not require a code bug. Repeated requests can still harm the business.

9. Leaking internals through errors

Stack traces, SQL details, internal service names, paths, and secrets should not appear in client-facing errors.

10. Not adding security regression tests

Security bugs often return when similar endpoints are changed. Add regression checks for high-risk authorization and token issues.

---

FAQ

What is a REST API Security Testing Checklist?

A REST API Security Testing Checklist is a defensive checklist for checking security risks in REST APIs.

It helps test authentication, authorization, BOLA, mass assignment, sensitive data exposure, token handling, API keys, CORS, rate limits, unsafe methods, error messages, logs, secrets, deprecated versions, and security misconfiguration.

How is REST API security testing different from API testing?

API testing checks whether an endpoint works correctly.

REST API security testing checks whether an endpoint can be used unsafely.

For example, API testing checks that GET /orders/{id} returns an order. Security testing checks that User A cannot access User B’s order through the same endpoint.

How is REST API security testing different from API pentesting?

REST API security testing checklist is a practical defensive QA/security review before release.

API pentesting is usually deeper, performed by a security specialist, and has formal scope, rules of engagement, reporting, and remediation process.

This checklist helps prepare for a pentest, but it does not replace one.

What should be checked in REST API security testing?

At minimum, check:

• HTTPS;
• authentication;
• token handling;
• object-level authorization;
• function-level authorization;
• mass assignment;
• sensitive data in responses;
• input validation;
• HTTP methods;
• CORS;
• rate limits;
• error messages;
• logs;
• secrets/debug data;
• deprecated API versions;
• production-safe security smoke.

What is BOLA in REST API?

BOLA means Broken Object Level Authorization.

In REST APIs, this often means that a user can change an object ID in the URL or request and access another user’s order, invoice, file, account, report, or workspace resource.

How do you test object-level authorization?

Create two test users or two tenants.

Check that User A cannot read, update, delete, or export User B’s object, even if User A knows or guesses the object ID.

How do you test function-level authorization?

Check that a regular user cannot directly call admin, owner-only, manager-only, or internal-only actions through the API.

For example, hiding an admin button in the UI is not protection. The API must enforce permission on the backend.

What is mass assignment in API?

Mass assignment is a situation where an API accepts extra fields from request body and applies them to an object without a strict allowlist.

For example, user sends an additional field such as role, price, owner, payment status, or account status, and the API applies it even though the user should not have permission to change it.

How do you check sensitive data exposure?

Inspect raw API responses, not only the UI.

Check that API does not return passwords, tokens, API keys, full payment data, admin notes, internal pricing, hidden fields, private user data, or debug information unnecessarily.

How do you test CORS for REST API?

Check allowed origins, credentials policy, allowed methods, allowed headers, and preflight behavior.

The API should not allow browser access more broadly than the product architecture requires.

How do you test rate limits?

Check that sensitive endpoints are protected from excessive requests: login, password reset, signup, search, export, file upload, checkout, coupon application, email/SMS sending, and other expensive flows.

How do you know REST API security testing passed?

REST API security testing can be considered passed when:

• protected endpoints require authentication;
• tokens are validated safely;
• users cannot access other users’ objects;
• roles and permissions are enforced server-side;
• protected fields cannot be modified;
• sensitive data is not exposed;
• unsafe methods are blocked;
• CORS is restricted;
• rate limits and abuse protections work;
• errors do not leak internals;
• logs are useful but do not contain secrets;
• deprecated versions do not bypass security;
• no blocker or critical API security issues remain.