FortiWeb-style application protection, API controls and measured tuning
Place the protection in the actual traffic path
A web application firewall examines relevant application traffic under its deployment mode, server policy and protection configuration. FortiWeb 7.4 documentation distinguishes reverse-proxy and transparent/offline arrangements. In a reverse-proxy scenario, clients address a configured front-end service and FortiWeb forwards to a selected back-end pool under policy. Other proxy modes can also proxy connections, so the phrase terminatesTCPalone is not a complete mode identifier. Determine destination addressing, topology and supported features from the stated version and design.
A server policy connects the relevant listener or matching conditions with the actual back-end service and protection controls. A virtual server, server pool and protection profile serve different roles. Installing an appliance does not prove that all traffic traverses it; alternate paths, direct back-end access, encrypted visibility and policy mismatches can change coverage. For TLS, specify which connection is terminated or protected, which keys and certificates are needed and how back-end identity is verified. Encryption on one leg does not automatically prove encryption or authentication on the other.
Match the control to the weakness
Signature checks, positive input models, file-upload constraints and API-schema validation investigate different application properties. A WAFdoes not replace server-side object authorization, parameterized queries or fixing vulnerable code. A normal-looking request can still ask for another customer’s private record. API inventory and learning can help expose unexpected endpoints, but observation coverage and model quality determine what is found. A schema describing a valid request shape does not itself authorize the requester.
Bot and rate controls need an explicit identity and measurement model. An address can represent many users behind a shared gateway, and a bot can change addresses. Browser challenges can affect legitimate automation or accessibility. Learned behavior depends on representative trustworthy observations, while anomaly is not synonymous with attack. Do not invent one universal request threshold, learning duration or guaranteed model outcome. A volumetric link-capacity problem can require controls beyond an application proxy.
Tune with evidence and recovery
Investigate the matched policy, rule, request context and response before adding a broad exception. Use approved test data and suitably controlled observation or staged enforcement. A narrow documented exception with ownership and review can differ from disabling an entire protection profile. Distinguish an internal forwarded-path rewrite from a client-visible redirect; they have different HTTP and application effects. Record configuration, health, logs and actual failover/recovery evidence under the selected topology. This chapter is written 7.4-era conceptual practice, not an assertion that every catalog question, menu label, feature licence or current exam offer matches every later build.