API Development & Security Testing Workflow: OWASP API Security Top 10 Guide

Use a layered approach:

1. SAST tools like Semgrep or SonarQube for code analysis
2. DAST tools like OWASP ZAP, Burp Suite, or Nuclei for runtime testing
3. API-specific scanners like Postman, Pynt, or 42Crunch
4. Fuzzing tools like RESTler for edge cases
5. OpenAPI validators for spec compliance.

Automate SAST and basic DAST in CI/CD pipelines. Use manual pentesting with Burp Suite for comprehensive security assessments before major releases.

Test BOLA by:

1. Authenticate as User A
2. Capture requests accessing User A's resources
3. Replay those requests while authenticated as User B
4. Check if User B can access User A's data.

Automate this by extracting resource IDs from responses and testing cross-user access. Tools like Burp Suite's Authorize extension automate BOLA testing. Look for sequential IDs (easy to enumerate), missing ownership checks, and inconsistent authorization between list and detail endpoints.

SAST (Static Application Security Testing) analyzes source code without executing it—finds vulnerabilities early, integrates with IDEs, but has false positives and can't find runtime issues. DAST (Dynamic Application Security Testing) tests running applications by sending requests and analyzing responses—finds runtime issues, tests real configurations, but requires a running application and is slower. Use both: SAST in development for early feedback, DAST in staging/CI for runtime validation.

Add security gates at each stage:

1. Pre-commit hooks with Semgrep for obvious issues
2. Build stage SAST scanning with threshold-based failures
3. Test stage API contract validation against OpenAPI specs
4. Staging stage DAST scanning with OWASP ZAP or Nuclei
5. Pre-production manual pentesting for critical releases.

Set appropriate thresholds—block builds on high/critical findings, warn on medium. Store security reports as artifacts. Integrate findings with issue trackers.

Cover:

1. Authentication testing—invalid tokens, expired tokens, brute force, credential stuffing
2. Authorization testing—BOLA, function-level access, privilege escalation
3. Input validation—injection attacks, boundary testing, malformed data
4. Rate limiting—bypass attempts, distributed attacks
5. Business logic—workflow manipulation, race conditions
6. Data exposure—verbose errors, excessive data in responses.

Map tests to OWASP API Top 10. Document test cases, expected results, and actual findings.

Test:

1. Token validation—expired, malformed, wrong algorithm, missing signature
2. Session management—logout effectiveness, token revocation, concurrent sessions
3. Credential handling—password complexity, lockout after failures, reset flow security
4. OAuth flows—state parameter validation, redirect URI validation, PKCE enforcement
5. Rate limiting on auth endpoints.

Never test production auth with real user credentials. Use dedicated test accounts. Monitor for credential exposure in logs.

Common false positives include:

1. Missing security headers on non-HTML API responses
2. CORS "issues" that are intentionally permissive for public APIs
3. Information disclosure findings for intentional public data
4. Rate limiting findings when limits are by design
5. Certificate warnings in development/testing environments.

Tune scanner rules for API context. Create a baseline of accepted risks. Focus human review on high-confidence findings and new vulnerability patterns.

API fuzzing tests edge cases with malformed inputs. Steps:

1. Generate test cases from OpenAPI specs using tools like RESTler or Schemathesis
2. Fuzz parameter values—boundaries, special characters, Unicode, oversized inputs
3. Fuzz parameter types—strings where numbers expected, arrays where objects expected
4. Fuzz headers—malformed auth tokens, invalid content types
5. Monitor for crashes, 500 errors, unexpected responses, timing anomalies.

Run fuzzing in isolated environments—it can corrupt data.

Track:

1. Vulnerability density—findings per endpoint or per 1000 lines of code
2. Mean time to remediation—how fast critical issues get fixed
3. Security test coverage—percentage of endpoints tested, OWASP categories covered
4. False positive rate—to tune scanner effectiveness
5. Regression rate—vulnerabilities reintroduced
6. Security debt—open findings by severity and age.

Set targets and track trends over time. Report to leadership with business context.