API Security Scanning Checklist: What to Test in REST, GraphQL, and gRPC APIs

Overview

A good API security scanning checklist does two things at once: it helps you find common technical weaknesses, and it keeps your testing process aligned with how your APIs are actually used. That matters because an API vulnerability scanner can only go so far if it does not understand your authentication model, input patterns, business logic, and deployment path.

For most teams, the most useful approach is layered:

• Discovery: Identify every externally reachable and internal API, including deprecated versions that still answer requests.
• Baseline scanning: Run automated security scanning for authentication, authorization, input handling, secrets exposure, and transport issues.
• Context-aware review: Validate high-risk workflows manually or with targeted tests, especially around object access and privilege boundaries.
• Prioritization: Focus first on issues that are reachable, reproducible, and tied to sensitive data or privileged actions.

This is also why API security scanning should not be treated as a standalone DAST task. It usually works best when paired with code and dependency checks. If your team is still defining where API testing fits, see SAST vs DAST vs SCA vs IAST: Which Security Scanning Approach Fits Your SDLC?.

The checklist below is organized by scenario so you can apply it to REST API security testing, GraphQL security scanning, and gRPC security testing without forcing one protocol into another protocol’s assumptions.

Checklist by scenario

Use this section as a working list before deployment, before enabling a new API vulnerability scanner, or when reviewing an existing service that has grown beyond its original design.

Universal API security scanning checklist

Start here regardless of protocol.

• Inventory the attack surface. Document public APIs, partner APIs, internal APIs, admin endpoints, staging environments, shadow endpoints, versioned routes, and legacy routes that may still be reachable.
• Verify authentication coverage. Confirm which endpoints require auth, which allow anonymous access, and whether scanners are testing both expected and unexpected access paths.
• Test authorization at object and function level. Check whether one user can read or modify another user’s records, and whether low-privileged users can access admin actions.
• Probe input validation. Send malformed types, oversized payloads, unexpected fields, special characters, nested structures, and duplicated parameters.
• Check error handling. Look for stack traces, framework errors, internal IDs, schema details, or environment-specific leakage in error responses.
• Review rate limiting and abuse controls. Test brute-force resistance, token abuse limits, pagination abuse, bulk export limits, and denial-of-service behavior.
• Validate transport security. Ensure TLS is enforced, plaintext alternatives are disabled where possible, and insecure downgrade paths do not exist.
• Scan for sensitive data exposure. Inspect responses, logs, headers, debug endpoints, and documentation artifacts for tokens, credentials, internal hostnames, or excessive PII.
• Test state-changing operations for replay and misuse. Examine idempotency, duplicate request handling, and whether predictable request patterns can trigger repeated changes.
• Map findings to business impact. Separate low-risk schema noise from issues that expose accounts, payment operations, secrets, regulated data, or privileged workflows.

REST API security testing checklist

REST APIs remain the most common integration surface, but they also accumulate hidden complexity through versioning, inconsistent auth, and endpoint sprawl.

• Enumerate all routes and methods. Test not just documented paths, but undocumented verbs such as PUT, PATCH, DELETE, OPTIONS, and HEAD where supported.
• Check broken object level authorization. Change identifiers in paths, query strings, and body parameters to see whether access controls rely too heavily on client-supplied IDs.
• Check broken function level authorization. Attempt privileged actions from standard user roles, including account management, export functions, billing actions, and tenant settings.
• Inspect parameter handling. Test mass assignment, hidden fields, duplicate parameters, type confusion, and server-side acceptance of fields the client should never set.
• Review pagination, filtering, and sorting inputs. These often hide injection points, enumeration risk, and unexpectedly expensive queries.
• Test content-type handling. Send JSON, form data, multipart payloads, and conflicting content-type headers to identify parser inconsistencies.
• Check file upload endpoints. Validate type restrictions, storage controls, antivirus or content scanning behavior, and public retrieval rules.
• Review CORS behavior. Confirm only intended origins are allowed, credentials are handled deliberately, and wildcard settings do not widen exposure.
• Validate version retirement. Older API versions may retain weaker auth rules or different validation logic long after clients have moved on.

GraphQL security scanning checklist

GraphQL changes the shape of testing because one endpoint may expose a very large underlying surface. Generic scans often miss GraphQL-specific abuse paths unless you provide schema awareness or targeted queries.

• Determine whether introspection is enabled. If it is, treat the schema as an exposed inventory source and assess whether that is acceptable for the environment.
• Review schema exposure. Test whether deprecated fields, admin types, internal mutations, or hidden relationships are still reachable through the schema.
• Check field-level authorization. It is not enough for the query to require auth overall; each sensitive field and resolver should enforce the right access rule.
• Test query depth and complexity limits. Send deeply nested queries, repeated fragments, and broad relationship traversals to measure server behavior.
• Test batching behavior. Assess whether aliases, batched requests, or repeated object fetches can bypass rate limits or amplify data extraction.
• Inspect resolver input validation. Validate mutations for unsafe object updates, over-posting, and trust in client-supplied ownership or role metadata.
• Review error messages. GraphQL implementations can expose detailed resolver paths, stack information, and schema clues that help attackers map the system.
• Check persisted query handling. If persisted queries are used, test fallback paths and confirm arbitrary queries are not still accepted unexpectedly.
• Test denial-of-service controls. GraphQL is especially sensitive to expensive queries, nested joins, and broad field selection without cost controls.

gRPC security testing checklist

gRPC can be easy to under-test because it often sits behind internal trust assumptions. In practice, internal APIs deserve the same attention as external ones, especially in microservice environments.

• Inventory services and methods from protobuf definitions. Treat proto files as part of the attack surface documentation.
• Validate authentication between services. Check mTLS configuration, token validation, service identity assumptions, and fallback behavior when certificates rotate or fail.
• Test authorization at method level. Confirm that sensitive RPC methods are not callable by any authenticated service by default.
• Inspect metadata handling. gRPC metadata can carry auth context and routing details; test for spoofing, trust of unsigned values, and leakage in error conditions.
• Fuzz message fields. Send unexpected enum values, oversized repeated fields, malformed nested messages, and boundary values for serialized types.
• Review streaming behavior. For client, server, or bidirectional streaming, test resource exhaustion, long-lived session abuse, and partial-message handling.
• Check error details and debug exposure. Internal services sometimes return verbose failures that reveal implementation details, hostnames, or backend structure.
• Verify gateway translation paths. If gRPC is exposed through REST or an API gateway, test both sides because auth and validation can diverge across the translation layer.

CI/CD and operations checklist for API scanning

A checklist is only useful if it fits the delivery process. For many teams, the hardest part is not deciding what to test but deciding when and where to test it.

• Run contract-aware scans in pre-production. Use realistic auth and test accounts so the scanner can exercise protected endpoints.
• Gate on high-confidence findings. Avoid blocking every build on noisy output; focus on exploitable, reproducible, or policy-defined issues.
• Retest after remediation automatically. Ensure closed findings are verified instead of manually marked resolved.
• Store evidence for audit readiness. Keep scan logs, coverage notes, exception records, and remediation timestamps for compliance-ready vulnerability management.
• Track scanner blind spots. Document what your tooling does not cover, such as business logic abuse, tenant isolation edge cases, or internal gRPC methods.
• Use prioritization to cut noise. Pair findings with exposure, asset criticality, and reachable data impact. For practical guidance, see How to Reduce False Positives in Vulnerability Scanning Without Missing Real Risk.
• Integrate with pipeline checks deliberately. Align API scans with broader CI/CD security scanning rather than treating them as a one-off quarterly exercise.

What to double-check

If time is limited, these are the areas worth reviewing twice because they are common sources of high-impact misses in API security scanning.

• Authentication assumptions. Scanners frequently test unauthenticated paths well, but miss flaws that appear only after login, token refresh, delegated access, or role switching.
• Authorization between similar users. Many serious API flaws are not admin-versus-user issues. They are user-A-versus-user-B problems, especially with predictable object identifiers.
• Tenant isolation. In multi-tenant systems, verify that filters, exports, search functions, and background jobs cannot cross tenant boundaries.
• Deprecated and undocumented endpoints. Old versions often keep weaker validation or broader data access even after the main application has matured.
• Generated documentation and schema endpoints. OpenAPI specs, GraphQL introspection, and protobuf artifacts can expose more than teams realize if left broadly reachable.
• Non-production environments. Staging and preview environments often have real data, relaxed auth, or experimental endpoints that never make it into formal inventory lists.
• Error-path behavior. A request that fails can reveal as much as one that succeeds. Pay close attention to verbose debugging output and inconsistent permission checks on error branches.
• Rate limits on privileged workflows. Login endpoints matter, but so do password reset, API token creation, invitation flows, export jobs, and search endpoints with expensive joins.

If you are evaluating tools, it can help to compare how your chosen DAST scanner or application security scanner handles authenticated crawling, schema import, stateful workflows, and API-specific replay. A broader buying lens is covered in Best DAST Scanners for Modern Web Apps: Features, Strengths, and Tradeoffs.

Common mistakes

Most API programs do not fail because teams ignore security completely. They fail because testing is partial, assumptions go unchallenged, or automation is added without enough context.

• Treating API discovery as solved. If you only scan documented endpoints, you will miss shadow APIs, stale versions, and internal services exposed through gateways.
• Equating authentication with authorization. A valid token does not mean every object, field, or method should be accessible to that caller.
• Running unauthenticated scans only. This gives a narrow picture and can create false confidence around protected surfaces.
• Ignoring protocol-specific risks. GraphQL depth abuse, gRPC metadata trust, and REST mass assignment do not appear in identical ways.
• Blocking delivery on untriaged scanner output. Excessive noise leads teams to bypass controls. Prioritized, high-confidence results are more sustainable than blanket gating.
• Skipping business logic review. Automated security scanning is essential, but it will not reliably catch every workflow misuse such as approval bypass, discount abuse, or export misuse.
• Testing only internet-facing APIs. Internal service APIs often hold broader privileges and weaker assumptions, making them attractive targets after initial compromise.
• Failing to align scanning with remediation ownership. Findings should map clearly to the team, service, and code path responsible for fixing them.

When to revisit

Revisit this checklist whenever the inputs change, not just when a formal audit approaches. In practice, that usually means reviewing your API security scanning coverage:

• Before seasonal planning cycles so tooling, coverage gaps, and ownership issues can be addressed before roadmap commitments harden.
• When workflows or tools change such as new auth providers, API gateways, service mesh changes, scanner replacements, or CI/CD redesigns.
• When a new API style is introduced for example adding GraphQL beside REST, or exposing internal gRPC services through a gateway.
• When sensitive data or privileged actions move into an API including billing, exports, partner integrations, administrative actions, or regulated records.
• After major schema or version changes because new fields and mutations often bypass assumptions built into earlier tests.
• After incidents, near misses, or recurring false positives to refine the balance between coverage, signal quality, and developer workflow fit.

A practical next step is to turn this article into a lightweight review routine:

1. List every API surface you own by protocol and environment.
2. Mark which parts are covered by automated security scanning today.
3. Identify the top five sensitive workflows per API.
4. Retest auth, authorization, data exposure, and abuse controls on those workflows first.
5. Document gaps your current API vulnerability scanner does not cover.
6. Decide which findings should block CI/CD, which should open tickets, and which need manual review.

That simple routine keeps API security scanning tied to actual risk instead of turning it into a checkbox exercise. The details of REST API security testing, GraphQL security scanning, and gRPC security testing will continue to evolve, but the core questions remain stable: what is exposed, who can reach it, what can they change, and how quickly can your team verify and fix the answer.