Testing Your API for Vulnerabilities Tools and Techniques

Building a secure API is not a one-time event. Security testing is an ongoing process that finds vulnerabilities before attackers do. This topic covers the tools and testing techniques used to evaluate API security — from automated scanning to manual penetration testing.

Types of Security Testing

Static Application Security Testing (SAST):
  Analyzes source code without running the application.
  Finds: Hardcoded secrets, SQL injection patterns, insecure function calls.
  When: During development, in CI/CD pipeline on every commit.
  Speed: Fast (seconds to minutes). High false positive rate.

Dynamic Application Security Testing (DAST):
  Tests the running application by sending real HTTP requests.
  Finds: Runtime vulnerabilities, misconfigurations, injection flaws.
  When: Against staging environment. Periodic production-safe scans.
  Speed: Slower (minutes to hours). Low false positive rate for confirmed issues.

Interactive Application Security Testing (IAST):
  Agents run inside the application and observe code during testing.
  Combines SAST accuracy with DAST coverage.
  When: During automated integration tests in CI/CD.

Penetration Testing (Manual):
  Human security tester actively tries to compromise the API.
  Finds: Logic flaws, complex authorization issues, chained attacks.
  When: Pre-launch for high-risk APIs, annually for production APIs.
  Duration: Days to weeks.

Bug Bounty Programs:
  External security researchers continuously test public APIs.
  Finds: Real-world vulnerabilities discovered by skilled external testers.
  When: Ongoing for publicly accessible APIs.

Essential API Security Testing Tools

Burp Suite

The industry-standard tool for manual API security testing.
Acts as a proxy between your test client and the API.

Key Features for API Testing:
  Intercept: Capture every API request and modify it before sending.
  Repeater:  Send the same modified request multiple times.
  Intruder:  Automated fuzzing — try thousands of input variations.
  Scanner:   Automated vulnerability scanner.
  Decoder:   Encode/decode Base64, URL encoding, JWT payloads.

Common API Test Workflow in Burp:
  1. Configure browser or Postman to use Burp as proxy (127.0.0.1:8080).
  2. Browse the application normally — Burp captures all requests.
  3. Send interesting requests to Repeater.
  4. Modify parameters: change user IDs, add SQL injection, modify JWT.
  5. Observe differences in responses to identify vulnerabilities.

Example — Testing for BOLA:
  Capture: GET /api/invoices/9901 (your invoice)
  In Repeater: Change 9901 to 9902, 9903, 9904...
  Look for 200 responses on IDs that do not belong to you.

OWASP ZAP (Zed Attack Proxy)

Free, open-source alternative to Burp Suite.
Excellent for automated scanning in CI/CD pipelines.

API Testing with ZAP:
  Import OpenAPI specification → ZAP generates test cases automatically.
  Active scan: Sends attack payloads to all discovered endpoints.
  Passive scan: Analyses traffic without sending extra requests.

ZAP in CI/CD (GitHub Actions example):
  - name: Run OWASP ZAP API Scan
    uses: zaproxy/action-api-scan@v0.5.0
    with:
      target: 'https://staging-api.company.com'
      format: openapi
      api_spec: './docs/openapi.yaml'
      fail_action: true    # Fails the build if HIGH findings exist

This automatically tests every API endpoint defined in the spec
on every pull request or deployment to staging.

Postman

Primarily a development tool, Postman is also used for security testing.

Security Uses:
  Manually craft and send edge-case requests.
  Test authentication flows step by step.
  Collection Runner: run hundreds of test cases automatically.
  Environment variables: easily switch between test accounts (UserA, UserB).

BOLA Testing with Postman:
  Collection 1 (UserA):
    POST /api/login (UserA credentials) → Save token to env variable
    GET  /api/orders → List orders, note order IDs belonging to UserA
  
  Collection 2 (UserB):
    POST /api/login (UserB credentials) → Save token to env variable
    GET  /api/orders/{UserA_order_id} → Should return 403
    → If returns 200: BOLA confirmed.

Postman also has automated test scripts:
  pm.test("Should not access other user's data", function() {
    pm.response.to.have.status(403);
  });

SQLMap

Automated SQL injection detection and exploitation tool.
Use ONLY on systems you have explicit permission to test.

Basic API SQL injection test:
  sqlmap -u "https://api.company.com/products?category=shoes" \
         --cookie="session=your_session_cookie" \
         --level=3 --risk=2 \
         --dbms=mysql \
         --dbs    # List all databases if injection found

Testing POST endpoints:
  sqlmap -u "https://api.staging.company.com/api/search" \
         --data='{"query":"test"}' \
         --headers="Content-Type: application/json" \
         --headers="Authorization: Bearer YOUR_TOKEN" \
         --level=3

SQLMap findings tell you:
  Whether the endpoint is vulnerable.
  What database engine is being used.
  What tables exist (if injectable).
  Can be used to extract data in authorized testing scenarios.

JWT Security Tools

jwt.io:
  Paste any JWT to decode header and payload instantly.
  Verify signatures with known secrets or public keys.
  Test the "none" algorithm vulnerability manually.

jwt_tool (Python, command line):
  Test for common JWT vulnerabilities automatically.
  python3 jwt_tool.py TOKEN --all   # Tests all known JWT attacks
  
  Tests include:
    Algorithm none attack
    HS256 signature without secret check
    RS256 to HS256 confusion
    Key id (kid) injection
    JWT expiry bypass

Jose / PyJWT libraries:
  Implement custom JWT manipulation for specific test scenarios.

Nikto and Other Reconnaissance Tools

Nikto:
  Web server scanner that detects outdated software, misconfigurations,
  and common vulnerabilities.
  nikto -h https://api.company.com -ssl

Gobuster / feroxbuster:
  Brute-force API endpoint discovery using wordlists.
  feroxbuster -u https://api.company.com -w /usr/share/wordlists/api_endpoints.txt
  
  Finds: Shadow APIs, admin endpoints, debug endpoints,
         undocumented paths.

Amass / subfinder:
  DNS enumeration to discover all subdomains.
  May reveal staging, dev, or internal API endpoints exposed publicly.
  amass enum -d company.com

Manual Testing Checklist

Authentication Tests:
  □ Can you access protected endpoints without a token?
  □ Does the API accept expired tokens?
  □ Does the API accept tokens with invalid signatures?
  □ Does the API accept JWT with algorithm "none"?
  □ Can you brute force the JWT secret? (use jwt_tool)
  □ Does the login endpoint have rate limiting?
  □ Does the password reset endpoint have rate limiting?

Authorization Tests (BOLA/IDOR):
  □ Create two accounts (User A, User B).
  □ With User A, access every resource endpoint.
  □ With User B's token, try every resource ID from User A.
  □ Any 200 response = BOLA.

Authorization Tests (BFLA):
  □ With a regular user token, try every admin endpoint.
  □ Try all HTTP methods on regular endpoints.
  □ Try accessing previous API version endpoints.

Input Validation Tests:
  □ Send SQL injection strings in all text parameters.
  □ Send scripts in text fields (XSS).
  □ Send oversized values (10MB string for a 50-char field).
  □ Send negative numbers, zero, floats where integers expected.
  □ Send null values for required fields.
  □ Send extra fields not in the API spec (mass assignment).
  □ Send XXE payload if endpoint accepts XML.

Data Exposure Tests:
  □ Check every response for fields not needed by the client.
  □ Check error messages for stack traces or DB info.
  □ Verify sensitive fields are masked (card, SSN, passwords).
  □ Check that 404 responses do not reveal resource existence.

Transport Security Tests:
  □ Check SSL Labs rating (aim for A+).
  □ Verify HTTP is redirected to HTTPS.
  □ Check HSTS header is present with adequate max-age.
  □ Verify all security response headers are present.

Rate Limiting Tests:
  □ Send >100 requests in 1 minute to each endpoint.
  □ Does the API return 429?
  □ Does the 429 response include Retry-After header?
  □ Can you bypass rate limiting by rotating IPs or User-Agents?

Integrating Security Testing into CI/CD

Security testing at every stage of the pipeline:

Developer Workstation:
  Pre-commit hooks:
    - Secret scanning (detect API keys, passwords in code)
    - SAST linting (detect common security code smells)
  Tools: pre-commit, gitleaks, semgrep

Pull Request / CI Build:
  - SAST: Full static analysis (Semgrep, Checkmarx, SonarQube)
  - Dependency vulnerability scanning (npm audit, OWASP Dependency-Check)
  - Unit tests including security-focused tests

Staging Environment Deployment:
  - DAST: OWASP ZAP, Burp Suite Enterprise automated scan
  - API schema validation testing
  - Authentication and authorization test suite

Pre-Production:
  - Manual penetration test (for major releases)
  - Full security checklist sign-off

Production:
  - Continuous monitoring and anomaly detection (Topic 23)
  - Periodic automated scans against production (passive/safe scans)
  - Bug bounty program

Fail build on:
  Critical or High severity SAST findings (no exceptions)
  Known critical CVEs in dependencies
  DAST findings rated High or above

Responsible Disclosure and Bug Bounty

For public-facing APIs, a security.txt file and bug bounty program
encourage researchers to report issues responsibly.

security.txt (at https://api.company.com/.well-known/security.txt):
  Contact: security@company.com
  Expires: 2026-01-01T00:00:00Z
  Encryption: https://api.company.com/pgp-key.txt
  Policy: https://company.com/responsible-disclosure
  Preferred-Languages: en, hi

Bug Bounty Platforms:
  HackerOne, Bugcrowd, Intigriti, Synack

Scope definition (what researchers can and cannot test):
  In scope:    api.company.com, staging-api.company.com (with permission)
  Out of scope: Production database, third-party services, DoS attacks

Reward structure (example):
  Critical (RCE, auth bypass):  ₹2,50,000 - ₹10,00,000
  High (BOLA, data exposure):   ₹50,000 - ₹2,50,000
  Medium (CSRF, minor leak):    ₹10,000 - ₹50,000
  Low (info disclosure):        ₹2,000 - ₹10,000

Key Points

  • Use SAST in development, DAST against staging, and manual penetration testing before major releases. All three catch different vulnerability types.
  • Burp Suite is the standard tool for manual API security testing. It intercepts, modifies, and replays requests to probe for vulnerabilities.
  • OWASP ZAP integrates into CI/CD pipelines to automatically test APIs on every deployment.
  • Always test with two accounts (User A and User B) to verify BOLA — access another user's resources using their IDs and your token.
  • Integrate security testing into every stage of the CI/CD pipeline: commit-time secret scanning, build-time SAST, deployment-time DAST.
  • A published responsible disclosure policy and bug bounty program harness the security research community to find issues before malicious attackers do.
Previous lessons
Back to courses
Next lessons

Leave a Comment