API protection fails when a team treats an API as merely another set of URLs behind a web application firewall. Modern APIs have methods, schemas, parameters, authentication states, object identifiers, business workflows, and data-exposure risks that ordinary signature matching cannot fully describe. FortiWeb 8.0 combines API discovery, schema-oriented controls, anomaly detection, bot defenses, and application-layer protections so the policy can reason about how an API is expected to behave.
Fortinet released the current NSE5-FWB-AD-8-0 exam in February 2026. Its scope explicitly includes API discovery and protection, reflecting the same operational requirement defenders face in production: protection quality depends on understanding the application contract before choosing what to block.
Start with an inventory of real endpoints and real callers
API security starts by answering what exists. Documentation and gateway configuration are useful, but they often lag production. Mobile clients may call older versions, partner integrations may use endpoints that developers rarely test, and internal services may expose routes that are reachable through a shared gateway. Discovery should therefore compare declared APIs with observed traffic.
Classify endpoints by function and consequence. Authentication, account administration, payment, data export, file upload, and search do not carry the same risk. Record expected methods, authentication requirements, caller populations, data types, and whether identifiers refer to objects owned by the caller. That context helps separate harmless variation from behavior that deserves stronger controls. API security fundamentals require an inventory that describes trust boundaries, object ownership, allowed operations, and authorization evidence rather than only URL paths. `/users/{id}` is not meaningful by itself; the policy needs to know whether a user may request only their own object, whether an administrator can request any object, and what evidence distinguishes those roles.
Schema learning is useful only when the training traffic is trustworthy
FortiWeb’s machine-learning API protection can learn methods, URLs, endpoint structures, and parameter patterns from observed requests. That can accelerate schema creation for APIs that lack clean specifications, but the model is only as trustworthy as the traffic used to train it. Learning during an active attack, a migration, or a load test can teach the system abnormal behavior as if it were normal.
Use a controlled learning window and compare the learned schema with application knowledge. New optional fields, versioned routes, or partner-specific parameters may be legitimate, while a rarely used administrative endpoint may deserve explicit treatment rather than broad automatic acceptance. Continuous learning can help adapt to schema change, but changes should still enter through an accountable deployment process.
Standby and alert modes are valuable before enforcement because they expose mismatches without immediately breaking clients. The goal is not to keep policy permanently passive; it is to collect enough evidence that enforcement failures are meaningful rather than artifacts of incomplete learning.
Schema validation catches structural abuse before business logic executes
Schema validation asks whether a request has the expected method, path, content type, fields, and data shapes. It can reject malformed requests that application code might otherwise spend resources parsing, and it reduces the attack surface created by undocumented inputs. Strictness is especially useful for machine-to-machine APIs where clients should already follow a contract.
Schema controls are not a complete authorization system. A request can be perfectly valid JSON, use the correct endpoint, and still access an object the caller should not see. Keep authentication and object-level authorization in the application or API platform, and use FortiWeb as an additional enforcement layer rather than a replacement for application identity decisions.
Versioning matters. When a new client introduces a field or moves from one API version to another, deploy the protection policy with the same release awareness. A schema that is technically correct for yesterday’s client can become a production outage after a legitimate release.
Threat models should include parameter behavior and data leakage
Attackers do not need malformed syntax if they can submit unusual values that trigger injection, enumeration, resource exhaustion, or unexpected application behavior. FortiWeb’s threat-protection learning can model parameter value patterns and identify requests that deviate substantially from expected behavior. Treat anomaly results as evidence to combine with signatures, reputation, authentication state, and endpoint sensitivity.
Response inspection is equally important. Sensitive-data leakage may occur when an API returns fields that the requestor should never receive, when verbose errors expose internals, or when an endpoint accidentally serializes a larger object than intended. Protection should cover both what enters the API and what leaves it.
Do not depend on generic regular expressions for every data type. Structured controls for API schemas, content types, and known sensitive-data patterns are easier to maintain than a large collection of overlapping custom signatures.
Authentication controls and rate limits need endpoint context
Rate limiting should reflect the operation. Ten password-reset attempts per second are different from ten catalog reads. Expensive search or AI-backed endpoints may need controls based on cost and concurrency, while token-validation endpoints may need protections against credential stuffing and enumeration.
Where identity is available, combine caller context with network and behavioral signals. One source IP can represent thousands of users behind a gateway, while one credential can move across many addresses. API defenses become more accurate when they can distinguish a partner service account, a customer session, and an anonymous client.
Be careful with automatic blocking when many legitimate clients share an egress address. A rule that blocks an IP for one abusive caller can deny service to an entire office, carrier, or partner. Choose enforcement keys and block duration according to the architecture.
Bot and automation defenses should distinguish good machines from hostile ones
APIs are designed for automation, so a simple human-versus-bot distinction is not useful. The policy must differentiate expected automated clients from scraping, credential attacks, enumeration, and abusive high-rate access. Known service identities, mTLS, API keys, signed requests, and stable client behavior can help identify legitimate automation.
Attackers can mimic headers and pacing, so do not base trust on a single fingerprint. Correlate identity, session state, request sequence, endpoint sensitivity, reputation, and behavior over time. A low-rate object enumeration attack can be more damaging than an obvious burst of malformed traffic.
Controls should also anticipate client retries. If a backend becomes slow and thousands of clients retry aggressively, legitimate automation can resemble a denial-of-service event. Protection needs enough observability to distinguish an application failure from a hostile surge.
API-specific attack testing should include authorization edge cases as well as malformed input. Try valid requests for another user’s object, repeated enumeration of sequential identifiers, unsupported methods, oversized bodies, duplicate parameters, and content-type mismatches. Some of these behaviors may be stopped by FortiWeb, while others properly remain application responsibilities. The exercise is valuable because it reveals exactly where each control layer begins and ends rather than assuming a WAF can enforce business authorization it cannot see.
Logging needs enough request context to reproduce a policy decision without storing unnecessary secrets. Preserve endpoint, method, response code, action, policy identifier, anomaly or signature reason, and a correlation ID that can be traced into application logs. Mask authorization headers, tokens, and sensitive payload fields. This balance makes a blocked request diagnosable without turning the security log into another repository of credentials and personal data.
Enforcement should move from evidence to blocking deliberately
Start by measuring what a proposed rule would affect. Which endpoints, clients, methods, and status codes are involved? Are violations concentrated in one outdated client or spread across all traffic? A rule should not move into blocking merely because the alert count is high.
Use staged enforcement for material policy changes: monitor, review false positives, narrow conditions, then deny. Maintain an emergency rollback path and keep policy changes traceable to an owner and deployment ticket. A disciplined web application testing should exercise valid, invalid, boundary, and adversarial inputs before production enforcement.
After enforcement, watch application error rates, latency, support incidents, and policy hits together. A security control that silently breaks a partner integration is still a production defect, even when it blocks exactly what the rule specified.
API keys and secrets should never be treated as ordinary request values in troubleshooting captures. Redact them at collection time where possible and restrict access to packet or body samples used for tuning. Security teams often need examples to understand a false positive, but keeping complete production payloads indefinitely can create a data-retention problem larger than the event being investigated.
API protection needs continuous review as the application changes
New endpoints, retired versions, authentication changes, schema evolution, and new client populations all alter the meaning of an existing policy. Review API inventory alongside application releases rather than waiting for a security incident to reveal that the protection model is stale.
Export and retain enough telemetry to reconstruct why a request was blocked: matched endpoint, policy, signature or anomaly, caller context, and request identifiers. Send high-value events into the organization’s investigation workflow instead of flooding the SOC with every low-confidence deviation.
Fortinet supplies the enforcement technology, and the Fortinet security-operations workflow determines what happens after a control fires. Effective API protection is a lifecycle: discover the contract, learn carefully, validate structure, detect behavior, enforce proportionately, and revise the policy as the application evolves.
