What is the difference between detective and preventive controls for public-facing APIs?

Detective controls look for weaknesses after they exist, such as vulnerability scans or reviews that identify exposure. Preventive controls actively block or stop attacks, such as a WAF or API security platform that can detect and prevent malicious activity. PCI DSS 6.4.1 allows either approach, while 6.4.2 requires the preventive model for web-facing applications.

Detective controls answer the “what is exposed?” question

For public-facing APIs, detective controls are designed to reveal exposure, misconfiguration, or insecure behaviour after it exists, so they are useful for finding gaps in coverage and validating assumptions. They do not, by themselves, stop a live request from reaching the API or prevent abuse if an exploit path is already available.

That distinction matters because APIs are often published into a changing environment where routes, methods, versions, and integrations evolve quickly. A detective control can tell you that the attack surface is present, but it depends on a follow-up action, such as remediation, to reduce the risk. For test coverage and post-change verification, teams often pair this with structured API testing from the OWASP API Security Top 10 and the OWASP Web Security Testing Guide.

Examples include vulnerability scans, security reviews, and periodic assessments that identify missing authentication, excessive exposure, weak input handling, or broken access logic. Those activities are valuable because they make hidden risk visible, but their control value is indirect: they inform the team, they do not intercept the malicious call in real time.

Preventive controls answer the “can the attack be stopped?” question

preventive controls are placed in the request path or security decision path so they can block, challenge, or constrain malicious traffic before the API processes it. For public-facing APIs, that usually means controls such as a WAF, an API security gateway, schema enforcement, rate limiting, authentication and authorisation checks, or a platform that can both detect and prevent abusive requests.

These controls are stronger when the failure mode is exploitation through predictable request patterns, known malicious payloads, or abusive volume. A preventive model reduces the chance that exposure becomes an incident, but it still depends on correct policy design, tuning, and exception handling. A control that blocks too broadly can break legitimate clients, while a control that is too permissive can give a false sense of safety. Guidance aligned to CIS Controls v8 and NIST SP 800-53 Rev. 5 commonly treats this as a combination of continuous enforcement, logging, and governance rather than a single product feature.

For public APIs, preventive controls are most effective when they are close to the enforcement point, validate both the request structure and the caller’s rights, and fail closed when the policy cannot be evaluated safely.

How to choose between them in practice

For a web-facing API, the practical decision is not “detective or preventive” as an either-or choice, it is which one carries the primary risk reduction job. Detective controls are better for discovery, assurance, and hygiene. Preventive controls are better when the API is exposed to real traffic and a bad request should never be allowed to succeed.

PCI DSS 6.4.1 permits either model for supported web application controls, while 6.4.2 requires a preventive approach for web-facing applications. That means the bar is different depending on the page, the exposure, and the scope of the control. In implementation terms, teams should use detective controls to prove what is present, then add preventive controls where the business cannot tolerate the request reaching the API at all, especially for sensitive operations or high-value endpoints.

Practitioner Guidance: Prefer detective controls when the goal is to find exposure and prioritise remediation, but treat them as insufficient for high-risk public endpoints because they depend on human follow-up.

What to verify: Confirm whether the control actually sits in the request path and enforces a decision before the API processes the request. If it only reports on exposure after the fact, it is detective, even if the reporting is excellent.

Decision rule: If the endpoint can cause material business impact, use preventive enforcement for the live control and keep detective testing as a validation layer, not the main barrier.

Practitioner takeaway: Public-facing APIs usually need both, but the security posture changes most when prevention is enforced at the edge and detection is used to prove the control still works over time.

Risk and Threat Considerations

Public-facing APIs create a direct exposure surface, so the main risk is that a weakness is not just observed but exercised immediately by an attacker or abusive client. Detective-only coverage can leave a window where the issue is known but still exploitable, especially for broken access control, injection, or automated abuse.

Failure mechanism: The control identifies the weakness after scanning or review, but the vulnerable endpoint remains reachable until someone remediates it or adds blocking logic.

Impact: Attackers can use the open path for data access, fraud, rate abuse, or deeper compromise before the organisation has time to act.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and PCI DSS v4.0 define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-4 — Access Control	API access must be enforced before requests succeed.
	DE.CM-8 — Vulnerability Scanning	Detective controls rely on scanning and review to find exposed weaknesses.
Recommendation — Enforce access decisions before processing public API requests. Use scanning to identify exposed API weaknesses and track remediation.
CIS Controls v8	16 — Application Software Security	API controls require secure testing, validation, and runtime protection.
	8 — Audit Log Management	Detective controls need logging to surface abuse and failed attempts.
Recommendation — Apply secure testing and runtime safeguards to public API endpoints. Log API activity so detection can reveal abuse and control failures.
PCI DSS v4.0	6.4.1 — Public-Facing Web Application Controls	The question directly references the PCI choice between detective and preventive models.
	6.4.2 — Public-Facing Web Application Controls, Preventive Approach	Public-facing web applications require preventive control for this PCI requirement.
Recommendation — Use either detective or preventive controls where PCI DSS permits either model. Implement preventive controls for web-facing applications that are in scope.
OWASP Agentic AI Top 10	A1 — Access Control and Authorization	API security depends on blocking unauthorized actions before execution.
	A3 — Input and Output Validation	Preventive API controls often stop malicious payloads at validation time.
Recommendation — Enforce authorization before a public API can process risky actions. Validate API inputs and outputs before requests reach business logic.

Practitioner Guidance

What to prioritise: Put preventive controls in front of externally reachable APIs that handle sensitive data or high-value actions, then use detective controls to confirm coverage and catch drift.

What to measure: Track whether blocked malicious requests are actually being stopped at the enforcement point, and whether scans or reviews are finding issues that should already have been prevented.

Common mistake: Treating scan results as equivalent to runtime protection. A clean scan is helpful, but it is not proof that the API cannot be abused in production.

Practitioner takeaway: The strongest pattern is layered control, preventive enforcement for live risk reduction, plus detective verification to keep the preventive layer honest as the API changes.