6.6 API & Web App Security Testing Concepts
Key Takeaways
- SAST analyzes source code without running it (early, broad, more false positives); DAST tests the running app from the outside (runtime, fewer false positives, later); IAST instruments the running app to combine both views.
- Burp Suite and OWASP ZAP are the intercepting proxies CEH expects you to know for manual web/API testing; sqlmap and Nikto automate specific scans.
- APIs widen the attack surface: per the OWASP API Security Top 10, the #1 risk is Broken Object Level Authorization (BOLA), so authorization must be enforced per object and per endpoint, server-side.
- Webhooks are inbound HTTP callbacks that must be authenticated (e.g., signature verification) and validated, or attackers can spoof events or trigger server-side request forgery.
- A Web Application Firewall (WAF) is a compensating control that filters malicious HTTP at the edge; a secure SDLC builds security into every phase so vulnerabilities are removed in code, not merely filtered.
Application Security Testing Methods
CEH expects you to distinguish the major automated testing approaches by when they run and what they can see:
| Method | What it is | Strengths | Limitations |
|---|---|---|---|
| SAST (Static Application Security Testing) | Analyzes source code/bytecode without executing it | Runs early (shift-left), sees all code paths, pinpoints the vulnerable line | More false positives, no runtime/config context, language-specific |
| DAST (Dynamic Application Security Testing) | Tests the running application from the outside, like an attacker | Finds runtime/config issues, language-agnostic, fewer false positives | Runs late, limited code visibility, may miss unreached paths |
| IAST (Interactive Application Security Testing) | Instruments the running app with sensors during functional testing | Combines code-level insight with runtime accuracy, low false positives | Requires instrumentation/agent, coverage depends on tests exercised |
A useful exam framing: SAST = inside-out, early; DAST = outside-in, runtime; IAST = inside-out during runtime. They are complementary, not substitutes.
Web/API Testing Tools CEH Tests
Manual testing dominates real web assessments, and CEH names specific tools:
- Burp Suite — the de facto intercepting proxy; its Proxy captures and modifies requests, Repeater replays single requests, Intruder fuzzes parameters, and the scanner finds common flaws. Burp appears in essentially every CEH practical web challenge.
- OWASP ZAP — the open-source equivalent proxy/scanner.
- sqlmap — automates detection and exploitation of SQL injection.
- Nikto — scans servers for known vulnerable files and misconfigurations.
- Postman / curl — craft and inspect raw API requests during testing.
API Security Considerations
Modern web applications expose Application Programming Interfaces (APIs) that are often more exposed than the user interface and easier to enumerate. The OWASP API Security Top 10 governs this space, and the dominant risks are authorization failures:
- Broken Object Level Authorization (BOLA / API1) — the #1 API risk: the API acts on an object ID without verifying the caller may access that object (the API-tier expression of IDOR).
- Broken Function Level Authorization (API5) — a lower-privilege caller can invoke an administrative endpoint because the check is missing or only enforced in the UI.
- Broken Object Property Level Authorization (BOPLA) — over-exposure of, or unauthorized writes to, specific object fields (combining excessive data exposure and mass assignment).
- Unrestricted Resource Consumption — no rate/resource limits, enabling brute force, scraping, and denial of service.
Defense: enforce authentication and per-object, per-function authorization server-side on every API call, return only required fields, validate input against a schema, and apply rate limiting. The principles match web app access control because an API is the application's access surface.
Webhook Security
Webhooks are inbound HTTP callbacks: a third-party service POSTs an event to a URL your application exposes. Because the endpoint is public and trusted to act on the event, it is a target. CEH-relevant risks and defenses:
- Spoofed events — anyone can POST to the URL. Defense: verify a signature (an HMAC of the payload using a shared secret) on every inbound webhook, and reject unsigned or mismatched requests.
- Replay attacks — resending a captured valid event. Defense: include and validate a timestamp/nonce.
- SSRF / abuse of outbound calls — if your app fetches URLs from webhook data, it can be coerced into requesting internal resources (now folded into Broken Access Control in OWASP 2025). Defense: allow-list destinations and validate URLs.
Web Application Firewall (WAF)
A Web Application Firewall (WAF) inspects HTTP traffic and blocks requests matching malicious patterns (known injection or XSS signatures, anomalous behavior) before they reach the application. CEH frames the WAF correctly as a compensating control: it buys time, blunts mass scanning, and provides virtual patching, but it can be evaded (encoding, fragmentation) and it does not remove the underlying vulnerability. A WAF complements secure code; it never replaces it.
Secure Software Development Life Cycle (Secure SDLC)
The strongest theme in this domain is that security is cheapest and most effective when built in, not bolted on. A secure software development life cycle (secure SDLC) embeds security activities into every phase:
- Requirements — security and abuse-case requirements alongside functional ones.
- Design — threat modeling; secure design patterns; address Insecure Design before any code exists.
- Development — secure coding standards, peer review, SAST in the pipeline, dependency/supply-chain checks.
- Testing — DAST/IAST, security regression tests, and targeted penetration testing.
- Deployment — hardened configuration baselines, secrets management.
- Operations — logging, monitoring, alerting, and a patch-management process feeding back into the cycle.
The takeaway CEH rewards: testing finds vulnerabilities, but only fixing them in code and designing securely removes them — which is why every section of this chapter ends on a root-cause remediation rather than edge filtering.
How an Ethical Hacker Tests a Web App or API
CEH ties these tools and concepts into a repeatable, authorized methodology:
- Scope and authorization — confirm written permission and rules of engagement before any testing; this is what makes the work ethical and legal.
- Reconnaissance and mapping — enumerate hosts, endpoints, and parameters (proxy the app through Burp Suite or ZAP, spider the site, import the API's OpenAPI/Swagger definition).
- Vulnerability discovery — automated scanning (Nikto, ZAP, sqlmap) plus manual probing for access-control gaps, which scanners miss.
- Exploitation/validation — safely confirm a finding is real (e.g., demonstrate an IDOR by accessing a test account's object), avoiding destructive actions.
- Reporting — classify each finding (often by OWASP category), rate severity, and recommend the root-cause remediation, not just a WAF rule.
Why Authorization Underlies Everything
Notice the recurring theme across the whole chapter: the most damaging web and API flaws — Broken Access Control, IDOR, BOLA, broken function-level authorization — are all failures to check who is allowed to do what on the server. Deny-by-default, server-side authorization on every request is the single most important web defense, which is exactly why OWASP ranks Broken Access Control number one.
A security team wants to detect vulnerable code patterns as early as possible, before the application is deployed or even runnable, by analyzing the source code directly. Which testing method fits this requirement?
According to the OWASP API Security Top 10, which is the number-one API risk, where an endpoint acts on an object ID without verifying the caller is authorized for that specific object?
Your application exposes a public webhook endpoint that a payment provider POSTs events to. What is the most important control to ensure the events are genuine?