Find and fix the security vulnerabilities in your API that automated scanners miss.

The API that returns all user data when you change the user_id parameter in the request has been in production for months. No automated scanner found it.

OWASP API Security Top 10 lists Broken Object Level Authorisation (BOLA/IDOR) as the #1 API security risk. It is also the risk that automated scanners are worst at detecting — because it requires understanding the application's business logic: what resources exist, what IDs they use, which endpoints should be scoped to the authenticated user, and whether changing an ID parameter returns data belonging to a different user. PROPELOO API security assessments are conducted by humans who read the API documentation, understand the business domain and actively try to access data they should not be able to access.

API security assessment coverage.

System Layers

• Reconnaissance Layer: API discovery, endpoint enumeration, schema extraction, technology fingerprinting
• Authentication Layer: JWT vulnerabilities, OAuth misconfiguration, API key exposure, MFA bypass
• Authorisation Layer: BOLA/IDOR, function-level access control, privilege escalation, resource ownership
• Business Logic Layer: Parameter manipulation, workflow bypass, rate limiting bypass, business rule violations
• Injection Layer: SQL injection via API parameters, NoSQL injection, SSTI, command injection

Core Technical Capabilities

• BOLA/IDOR Testing

  Systematic testing for broken object level authorisation — change every ID parameter in every endpoint to determine if the API correctly restricts access to the authenticated user's resources only.

• Authentication Testing

  JWT algorithm confusion attacks (RS256 to HS256), JWT none algorithm, weak secret brute force, OAuth misconfiguration (open redirect, token leakage), API key enumeration, MFA bypass.

• GraphQL-specific Testing

  Introspection abuse, query batching abuse, nested query DoS, field suggestion exploitation, mutation authorisation bypass, subscription authorisation, schema stitching vulnerabilities.

• Rate Limiting Testing

  Account enumeration via timing, brute force without lockout, API key enumeration, business logic abuse via excessive requests, parameter pollution to bypass limits.

• Injection via API

  SQL injection in query parameters, path parameters and request body. NoSQL injection in MongoDB query operators. SSTI in template rendering endpoints. Path traversal in file access endpoints.

• Mass Assignment

  Test whether APIs accept undocumented request body fields that update privileged properties — e.g., setting is_admin: true, changing another user's balance, bypassing payment requirements.

How we think about API security.

Automated scanners test for signatures of known vulnerabilities. A human tester asks: what is this API trying to protect, and what is the easiest way to get it without being authorised?

• Read the API documentation like an attacker

  Before sending a single request, we read the API documentation to understand: what resources exist, what their ID formats look like (numeric IDs are easier to enumerate than UUIDs), which endpoints are scoped to the authenticated user and which are supposed to be global, and what business operations could be financially valuable if bypassed.

  Axiom:

• BOLA is found by systematic ID substitution

  Testing for BOLA requires: authenticating as User A, finding a resource owned by User A (order ID, document ID, account ID), then sending the same request authenticated as User B. If User B can read User A's resource, that is BOLA. This test must be run on every endpoint that accepts a resource identifier. Automated scanners do not do this systematically because they do not know which IDs belong to which user.

  Axiom:

• GraphQL introspection maps the entire attack surface

  When GraphQL introspection is enabled (as it often is in development and staging), a single query returns the entire schema — all types, all fields, all mutations and queries. This is an attacker's starting point: identify sensitive mutations (deleteUser, updateBalance), identify fields that should require elevated permissions, and systematically test whether those permissions are enforced.

  Axiom:

• Mass assignment is the most commonly missed vulnerability

  Many APIs built with ORM frameworks automatically map all request body fields to model properties. If the user model has an is_admin field that is not intentionally excluded from mass assignment, a request with is_admin: true may successfully escalate privileges. The only way to find this is to add every privileged-sounding property to API requests and check if they are accepted.

  Axiom:

API security assessment scope decisions.

• Authenticated vs unauthenticated testing?

  Impact: Multi-user authentication is required for BOLA testing — you need at least two test accounts to verify that User A cannot access User B's resources. Single-user testing misses the most common critical API vulnerability.

  • Unauthenticated only — finds exposed endpoints, misses most API security
  • Authenticated (single user) — finds auth bypass, misses BOLA
  • Multi-user (authenticated as multiple accounts) — finds BOLA, correct for most APIs
  • Privileged + unprivileged — finds vertical privilege escalation

• Black box vs grey box?

  Impact: Grey box is the standard for API security assessments — access to the API documentation significantly increases test coverage and efficiency compared to pure black box discovery.

  • Black box (no documentation) — mimics external attacker, slower, less coverage
  • Grey box (API documentation + accounts) — most realistic, standard for most assessments
  • White box (source code + tests) — highest coverage, finds what code review would catch too
  • Hybrid (grey box + source review for critical paths) — best coverage for security-critical endpoints

• REST vs GraphQL vs gRPC testing?

  Impact: Include all API protocols in scope. GraphQL requires specific additional testing (introspection, complexity limits). gRPC requires specialised tooling (grpcurl, grpc-tools) and Protobuf schema analysis.

  • REST only — standard, most tooling support
  • GraphQL additional — introspection testing, batching abuse, nested queries
  • gRPC — Protobuf schema analysis, method enumeration, requires specialized tools
  • All protocols in scope — complete coverage, longer timeline

• Business logic testing depth?

  Impact: OWASP API Top 10 + custom business logic testing for the highest-value endpoints (payment, authentication, data export). Pure OWASP compliance testing without business logic review misses the most impactful issues.

  • OWASP API Top 10 only — structured, comprehensive for known issues
  • OWASP + custom business logic — requires understanding the domain
  • Full adversarial testing — attacker mindset throughout, highest coverage
  • Compliance only — meets requirement, limited security value

• Rate limiting bypass testing?

  Impact: Advanced rate limit testing including bypass techniques (X-Forwarded-For header manipulation, parameter pollution) and business logic rate limits (abuse of promotional codes, bypass of purchase limits).

  • Basic rate limit testing — does a rate limit exist?
  • Advanced bypass — IP rotation, header manipulation, parameter pollution
  • Business logic rate limits — can you exceed purchase limits, apply discounts multiple times?
  • No rate limit testing — missing a significant attack surface

• Automated vs manual?

  Impact: Automated tools (Burp Scanner, Nuclei) for known vulnerability patterns. Manual testing for: BOLA/IDOR (requires multi-user context), business logic flaws (requires domain understanding), and GraphQL-specific issues.

  • Automated only — fast, misses business logic and BOLA
  • Manual only — thorough, slow, expensive
  • Automated first, manual for confirmed findings — efficient
  • Automated for known patterns, manual for application-specific logic — correct split

What PROPELOO tests.

• REST API Penetration Test

  Full OWASP API Top 10 coverage with multi-user BOLA testing, authentication bypass, mass assignment and business logic abuse.

• GraphQL Security Assessment

  Introspection analysis, query complexity DoS, batching abuse, mutation authorisation bypass and subscription security.

• Authentication Deep Dive

  JWT algorithm confusion, OAuth misconfiguration, API key enumeration, MFA bypass and session management vulnerabilities.

• Pre-launch API Review

  Security assessment before production API launch — find critical issues before they affect users.

• Continuous API Security

  Regular API security testing cadence — quarterly manual review + automated testing in CI pipeline.

• Partner API Security

  Security review of APIs being opened to external partners — ensure partner access cannot be abused to access other partners' data.

The API security testing toolchain.

• Proxy & Interception

  Stack: Burp Suite Pro, OWASP ZAP, mitmproxy

• API Testing

  Stack: Postman (collections), HTTPie, curl, Insomnia

• GraphQL

  Stack: GraphQL Voyager (schema viz), InQL (Burp plugin), clairvoyance (introspection), graphql-cop

• Automated Scanning

  Stack: Nuclei (API templates), Burp Scanner, OWASP ZAP active scan, sqlmap (injection)

• JWT Testing

  Stack: jwt_tool, jwt.io (decode/verify), Custom Python scripts

• Reporting

  Stack: Dradis, Custom report templates, CVSS v3.1 calculator

API security assessment methodology.

• OWASP API Top 10 coverage

  BOLA, Broken Authentication, Object Property Level Authorisation, Unrestricted Resource Consumption, Function Level Authorisation, Server-side Request Forgery, Security Misconfiguration, Lack of Protection from Automated Threats, Improper Inventory Management, Unsafe Consumption of APIs.

• BOLA/IDOR testing protocol

  Two test accounts minimum. Systematic substitution of every resource ID across every endpoint. Vertical and horizontal privilege escalation. Resource enumeration via sequential IDs.

• JWT security tests

  Algorithm confusion (RSA to HMAC), none algorithm, key injection, claim tampering, token replay, signature bypass, expiry bypass.

• OAuth/OIDC testing

  Open redirect for token theft, PKCE bypass, state parameter CSRF, token leakage in referrer/logs, scope escalation, implicit flow vulnerabilities.

• GraphQL-specific tests

  Introspection enabled, depth limiting absent, query complexity unlimited, batching abuse, aliases for rate limit bypass, field suggestions as enumeration.

• Mass assignment testing

  Add every privileged-sounding field (is_admin, role, balance, credit_limit, verified) to every POST/PATCH request body. Document which fields are accepted.

From scoping to remediated API.

1. 01. Scoping

   Define API endpoints in scope, test account provisioning, documentation review, testing timeline.

2. 02. Reconnaissance

   Endpoint discovery, schema extraction (GraphQL introspection), technology fingerprinting.

3. 03. Automated Testing

   Burp Scanner, Nuclei API templates, SQLMap for injection, automated OWASP checks.

4. 04. Manual Testing

   BOLA/IDOR with multi-user accounts, authentication bypass, business logic testing, GraphQL-specific testing.

5. 05. Exploitation

   PoC for critical/high findings — demonstrate real data exposure or privilege escalation.

6. 06. Report Delivery

   Executive summary + technical findings with reproduction steps, CVSS scores and remediation guidance.

7. 07. Re-test

   Verify fixes for critical/high findings, confirm no new issues introduced, issue final attestation.

Frequently Asked Questions