Fortinet FortiWeb 7.4: Legacy WAF Administration

A customer portal is reachable through FortiWeb, but a legitimate application update introduces a JSON field that begins triggering a security policy. Administrators face a consequential choice: disable a broad web-application protection rule, or determine whether the newly observed request is authorized and adjust only the specific detection. A web application firewall sits close to valuable business transactions; its false positives can cause outages, while weak exception controls can expose sensitive data. FortiWeb 7.4 administration is about making that inspection precise and dependable.

FCP-FWB-AD-7.4 represents the historical FortiWeb 7.4 Administrator exam, which Fortinet listed with a final delivery date of May 31, 2026. The newer FortiWeb 8.0 Administrator examination was released on February 11, 2026. The 7.4 objectives remain useful for historical study, but candidates scheduling a new exam should use the current official FortiWeb assessment rather than assume the retired 7.4 version is available. The operational skills remain recognizable: server objects, reverse-proxy deployment, HTTP behavior, policy learning, signatures, API protection, logging, and controlled change. Those skills belong within the wider set of Fortinet certifications, but they do not replace the distinct duties of firewall or endpoint administration.

Map the complete HTTP request path before inspecting it

An application can appear healthy when accessed directly but fail through FortiWeb because the reverse proxy changes TLS termination, forwarded client attributes, header treatment, timeouts, or routing. Document each hop from client DNS through load balancing and FortiWeb to the web origin. Identify whether encryption ends at FortiWeb, whether the back-end is re-encrypted, and which hostname the application expects. When a request fails, distinguish a network reachability issue from an HTTP rule violation or back-end application error.

A good commissioning test uses representative authentication, upload, session, and API requests. Record expected status codes and how the application handles redirects or cookies. If X-Forwarded-For or similar information is used, confirm the trust boundary and prevent clients from forging headers that the application treats as authoritative. Session persistence and high availability choices should follow application semantics. The purpose of mapping is to avoid enabling exceptions in response to a failure that is actually caused by incorrect proxying.

Use server objects and protection profiles deliberately

Define application server pools, health checks, virtual listeners, and security policies from explicit application requirements. Different applications may need different maximum request sizes, allowed methods, content types, URL structures, and authentication behavior. Reusing one broad profile for a public commerce site and an internal JSON API can produce poor coverage for both. Treat policy inheritance and object naming as operational concerns because staff must know which change will affect which application during an incident.

When onboarding an origin, verify monitoring from FortiWeb's perspective rather than a separate workstation. A healthy TCP handshake does not prove the application returns a useful page. Ensure the WAF's bypass and failure behavior is intentional and approved. Test both permitted and denied requests; a profile that blocks the demonstration attack but also breaks legitimate checkout has not met the business requirement. Preserve an evidence-based baseline so future rule updates can be assessed against the real customer transactions they protect.

Differentiate anomaly, signature, and bot signals

Web threats include malformed protocol behavior, known exploit patterns, automated scraping, credential attacks, malicious file uploads, and business-logic abuse. No single detection method sees every class. Signature inspection can help recognize known attack forms; anomaly or learning-based analysis identifies deviation but can misclassify unusual legitimate traffic; bot controls make judgments about client behavior and challenge responses. Administrators must know which signal fired and which parts of the transaction it actually examined before interpreting a block as proof of attack.

Use log samples to compare an accepted normal request with the rejected one. Look at method, path, parameters, headers, session context, and the specific policy action. A narrowly scoped exception for one validated parameter is different from disabling SQL injection inspection for an entire site. Evaluate false-positive impact, privilege level, and data sensitivity before changing enforcement. If a policy requires a monitoring period, define a threshold and time to move into blocking mode; indefinite monitor-only configurations should not be mistaken for protection.

Treat API security as a data contract

APIs often exchange structured JSON, enforce authorization by token, and expose resources without a browser session. They require validation of request methods, paths, parameter types, size, and permissible object identifiers. A syntactically valid API request can still attempt unauthorized access to another customer's record, so input validation does not replace application authorization. Align WAF policy with published API specifications and observe what happens when the API version changes. Blanket exceptions for mobile clients or partner integrations can create unintended attack routes.

When an API endpoint starts failing after a rollout, compare the requested schema and the current application contract. An unexpected optional field may indicate a harmless release, or it may be an attempt to exploit an unsafe deserialization path. Ask the application owner for evidence instead of making the WAF accept anything that parses. Keep deployment records so changes in detection behavior can be correlated with code releases. Useful WAF policy decisions demand that protection controls are evaluated as part of application design rather than appended at the end.

Plan TLS, certificates, and high availability together

A public web service's certificate chain, private-key custody, supported protocols, and renewal process belong in the WAF operating model. A certificate failure can be mistaken for a policy block if the only reported symptom is that the customer cannot complete a secure connection. When FortiWeb terminates TLS and re-encrypts traffic to the origin, treat the back-end trust boundary as seriously as the public edge. Define whether services fail closed or remain reachable through an alternate protected route when a WAF component is unavailable.

High-availability testing should exercise both client and origin connectivity after a failover, not merely confirm a cluster status indicator. Watch for session changes, unexpected origin selection, certificate differences, and cache behavior. A configuration backup should include a secure recovery method for certificates and keys without exposing them in routine administration. Test controlled upgrades against actual application workflows, especially authentication, file upload, and transactions that rely on session state. Operational survivability and protection accuracy must be validated together.

Use logs to improve a policy without hiding threats

Security logs need to answer why a request was allowed, blocked, challenged, or merely observed. Integrate WAF records into authorized central analysis, but avoid transmitting unneeded sensitive payload data. Correlate WAF event identifiers with application traces so analysts can distinguish an attacker-triggered rule from a genuine app error. Reports should show protected endpoints, rule actions, significant trends, and the exceptions introduced over time. A falling block count is not necessarily an improvement if the WAF stopped logging or a broad bypass rule was added.

Review policy exceptions after releases, and assign each to an owner. Set a measurable condition for removing temporary bypasses. If an application has frequent false positives, the right response may be to improve its specifications or normalize its behavior rather than repeatedly weaken the WAF. An effective detection program grows more accurate through evidence from allowed and rejected traffic; it does not simply accumulate signatures and declare success based on product feature counts.

Understand learning modes and the boundary of automatic tuning

Application learning can speed the initial profile by observing legitimate request structures, URLs, and parameters. However, the learning window is also a security decision: if malicious traffic is present, accepting all observed patterns may teach the system to regard an attack as normal. Define representative users, expected transaction types, and a bounded observation period. Have an application owner review generated suggestions instead of applying every proposed change automatically. Where the application uses frequently changing paths or identifiers, distinguish the stable structural rule from incidental values. That prevents a profile from becoming both too permissive and too brittle.

Re-test protection after accepting learned behavior. Send valid requests at realistic volume, ensure sessions and uploads still work, and test intentionally malformed requests against the protections that should remain active. Keep the policy revision and reviewer identity with the change record. Learning is useful when it reduces avoidable noise while preserving a real denial boundary, not when it simply converts recent traffic into permission. This is particularly important during application modernization, where a new API or client release changes normal behavior and may coincide with attempts to exploit newly exposed endpoints.

Rehearse the legacy-to-current study transition

Build a small web service with forms, a JSON API, and a file-upload endpoint behind FortiWeb. Create ordinary user transactions, then introduce invalid methods, excessive payloads, unusual parameters, and a broken origin health check. Predict whether each should be blocked, allowed, or routed to application-level authorization. Examine logs for the precise enforcement reason and tune only after documenting legitimate behavior. Repeat with a deliberately expired certificate to isolate connection-level faults from application-policy faults.

A learner using 7.4 material should map these stable concepts to the current 8.0 course and its official objectives. Candidates should treat the 7.4 examination as retired in 2026, even when revising its still-useful WAF administration topics. In practice, the most valuable knowledge is the ability to protect a real application while keeping it available, observable, and recoverable, using tested conditions instead of indiscriminate exceptions.