FortiWeb 7.4 Administrator: Protecting Real Application Traffic

FCP_FWB_AD-7.4 identifies the FortiWeb 7.4 Administrator examination. Fortinet's official retirement schedule places its last delivery on May 31, 2026. The version-specific curriculum remains useful to administrators maintaining 7.4 deployments, but the retired assessment is not a currently available test. New candidates need the active version listed in Fortinet's training catalog, while administrators supporting existing 7.4 deployments still need to understand the reverse-proxy, web application firewall (WAF), bot protection, and API security decisions that made the platform useful.

A WAF operates on application semantics rather than simply ports and network addresses. HTTP methods, URLs, headers, cookies, sessions, file uploads, and API payload structure can all affect whether a request is legitimate. FortiWeb's job is to apply rules and learned expectations while preserving valid application behavior. Its deployment involves TLS, routing, virtual services, backend pools, logging, and exception governance. It sits alongside but should not be confused with FortiGate firewall administration, whose general network policy cannot replace specialized inspection of application-layer requests.

Select a deployment path that preserves application correctness

The first design question is how FortiWeb will sit in the application's request path. Reverse-proxy and other supported operating modes have different implications for addressing, TLS termination, client-IP visibility, and failure handling. Map the public service, upstream and downstream networks, application servers, certificates, authentication expectations, and health checks before creating policies. A request may be correctly inspected by the WAF but reach the wrong backend because its Host header, destination mapping, or route does not match the application's expectation.

When SSL/TLS is involved, establish who terminates the client connection and whether FortiWeb establishes a separate encrypted connection to the backend. Certificate names, trust chains, server-name indication, supported protocols, and renewal ownership must align with both sides. A client-side certificate warning is not the same fault as a FortiWeb backend handshake rejection. Proxy headers may be needed to tell the application the original client address or scheme, but those headers must be trusted only from known proxies; accepting a user-supplied identity header can corrupt audit records or application authorization decisions.

Load balancing and monitoring should reflect application health. A simple TCP port check may pass while an application returns authentication errors or a failed database transaction. Choose representative checks with the application owner and understand whether they create side effects. If traffic is distributed among several servers, ensure session behavior, persistence, and backend certificates are compatible with the design. Failover and maintenance tests should verify user journeys, not merely the presence of a healthy virtual service indicator.

Combine signatures, baselines, and learned protection

WAF protection uses more than a single rule type. Known attack patterns and signatures can block common exploit payloads, while positive security models can define acceptable URLs, parameters, methods, or content characteristics for a specific application. Learning mechanisms may observe traffic and propose expected behavior; they do not automatically know which unusual request is authorized. A new API release can legitimately change payload fields or endpoint paths. Approving every observed deviation weakens policy, while enforcing an immature baseline can cause widespread false positives.

Take an application that accepts JSON orders through an API endpoint. A request with an unexpected field might be a client-version mismatch, malicious parameter manipulation, or an approved feature introduced by another team. Analyze the API contract, request origin, authentication state, and backend processing before deciding. Negative signatures can address known exploit patterns, but a positive model may detect structurally unexpected requests that lack a known signature. Both approaches require maintenance as the application evolves.

Tune protection using narrow evidence. If a rule blocks a valid request, identify its exact match condition and reproduce the case in staging. Consider whether the problem is malformed application behavior that deserves correction, a WAF false positive, or a policy applied to the wrong URL group. Make the smallest justified exception and document the application owner and expiry. Avoid globally disabling request inspection to pass a single transaction; that turns an application issue into a broad security regression.

Protect sessions, bots, and machine-facing APIs

Web attacks often target business workflows rather than a single URL. Login pages face credential stuffing and brute-force attempts; purchase flows may be scraped or automated; API endpoints may receive excessively frequent or malformed requests. Bot mitigation and rate controls must distinguish automation that the organization permits, such as approved health checks or partner clients, from harmful traffic. An IP-based rule may accidentally block many legitimate users behind a shared gateway, whereas an identity-aware control can provide a more precise signal where the application supports it.

Session cookies and client state deserve careful inspection. Security attributes, integrity and lifecycle controls affect whether a stolen or manipulated session can be reused, but WAF policy cannot compensate for broken application authorization. Cross-site scripting, SQL injection, and other input-based threats should be evaluated with the web application's actual parsing behavior in mind. A signature match is a useful detection, not proof that exploitation succeeded. Preserve samples safely and avoid copying active payloads into production systems during analysis.

API traffic creates separate operational needs. APIs use machine identities, structured schemas, rate expectations, and version contracts that may differ sharply from a browser interface. Understand which protections rely on discovery, schema enforcement, token claims, and transport security. If a partner integration fails after a WAF rule update, compare the request's method, path, headers, authentication and body shape against the approved contract. Coordinating with the API owner is usually safer than allowing an entire endpoint without inspection.

Another deployment issue is how FortiWeb handles unusually large but legitimate requests. File-upload limits, payload inspection capacity, buffering, timeout behavior, and upstream server expectations can interact. If a financial document upload works directly to the test application but fails through the proxy, compare allowed body size, content type, request duration, and inspection event before assuming malicious activity. Test an approved maximum-size upload and a deliberately unsupported payload. The resulting policy must protect the application while documenting which large requests are part of its contract, rather than relying on an unlimited bypass.

Use analytics to explain blocking and tuning decisions

FortiWeb logs can show attack detections, rule matches, request metadata, origin and backend context, but their meaning depends on how logging is configured. A request blocked by the WAF may never reach the application; an application error returned after an allowed request should be investigated at the backend. Correlate timestamps and request identifiers where available. Establish whether client address data has been modified by an upstream proxy or NAT device before interpreting patterns by source IP.

Monitor detection trends alongside application experience. A rising blocked-request count could mean more attacks, a faulty integration, a new application release, or a recently tightened policy. Compare legitimate transaction success, support complaints, and representative logs before declaring improvement. Reports should state which applications and time ranges they cover. Where WAF telemetry is forwarded into broader FortiAnalyzer analytics, check whether event types and parsing preserve the distinctions between signature matches, action taken, and user-facing outcome.

Operational health includes certificate expiry, service reachability, resource capacity, backend monitor state, configuration backups, and the availability of the management plane. A policy is only protective when relevant traffic actually passes through FortiWeb. Validate that alternate routes, maintenance modes, or misconfigured load balancers do not bypass inspection. Review which administrators may edit global policies versus application-specific exceptions, and keep changes reversible.

Rehearse a release and a false-positive investigation

An effective lab uses a small test application with predictable URLs and an API endpoint. Configure a supported FortiWeb deployment, establish a working transaction, and apply basic protections in a non-disruptive observation mode where appropriate. Trigger a known benign malformed request, view its event, and inspect how the policy would handle it. Then change the application's API schema deliberately and examine whether the existing positive model rejects a newly legitimate request. The point is to practice determining why a request differs, not just whether the product labels it suspicious.

Stage a controlled policy edit with pre-change evidence, application-owner approval, post-change allow/deny tests, and a rollback path. Include a certificate validation failure or a backend-monitor mismatch to practice separating transport from application inspection. The FortiWeb 7.4 exam itself is now retired, but these habits remain the durable learning outcome: design the request path correctly, protect application semantics, and revise controls only after evidence distinguishes legitimate evolution from abuse. Use current documentation before migrating to a later FortiWeb version, since features and interfaces change even when the security principles remain sound.

A particularly revealing acceptance test compares the same business transaction through FortiWeb and through an authorized nonproduction control path that bypasses WAF inspection. The two responses should be compared using consistent input, user identity, and backend state; differences help isolate inspection, header rewriting, or TLS handling. This comparison is not permission to bypass production security indefinitely. It is a bounded diagnostic technique that allows the application owner and security team to determine whether the WAF caused the observed failure or merely exposed a defect already present downstream.

Certificate rotation provides another realistic operational scenario. Map where each certificate is installed, which hostname it represents, and which team owns its renewal. Test the management alert, staging installation, client trust, and backend handshake before the actual expiration window. Then verify that the application still receives the correct original-scheme and host information. A WAF can be technically healthy while application redirects loop because it no longer knows the request arrived over HTTPS. Troubleshooting this requires attention to proxy headers, application configuration, and which upstream devices are trusted to supply those values.