FortiWeb (WAF)

FortiWeb WAF is Fortinet's web application firewall, protecting public-facing web applications and APIs against the OWASP Top 10, botnets and application layer exploits. On top of the classic inspection layer made up of attack signatures, IP reputation and protocol validation, it adds a second detection layer based on machine learning; it runs as hardware, virtual machine, container, cloud and SaaS, and helps meet the client-side requirements of PCI DSS 4.0.

Current breach data shows why this layer is a separate line item in the budget. According to Verizon's 2025 Data Breach Investigations Report, vulnerability exploitation reached a 20% share as an initial access vector in breaches and rose by 34% compared with the previous report; edge devices and VPNs, meanwhile, accounted for 22% of exploitation targets — a year earlier that figure was 3% (Verizon DBIR, 2025). On the European side, ENISA's Threat Landscape 2025 report examined 4,875 incidents and found that vulnerability exploitation accounted for 21.3% of initial accesses (ENISA, 2025). When the speed at which an attacker weaponises a new flaw regularly outpaces the speed at which the development team produces a patch, the inspection layer in front of the application becomes the only realistic buffer.

Which attacks does FortiWeb block?

FortiWeb stops requests that target application logic directly: OWASP Top 10 categories, cross-site scripting (XSS), SQL injection, cross-site request forgery (CSRF) and session hijacking are at the top of the list (Fortinet FortiWeb Data Sheet, 2025). Within the same policy engine there are also protocol validation, HTTP RFC compliance, brute force protection, cookie signing and encryption, syntax-based SQLi/XSS detection, HTTP header security, threat scoring and weighting, data leak prevention, web page defacement protection and Man-in-the-Browser protection.

This does not replace protection at the network layer; it complements it. While the FortiGate next-generation firewall evaluates the session at the network and application recognition level, FortiWeb inspects the body, query parameters, cookies and headers of an HTTP/HTTPS request in the context of the protected application's own behaviour model. An NGFW's application control says "this traffic is going to a web application"; a WAF can say "this request is not in the expected form for this field of this application". In organisations that publish public-facing payment, application or customer portals, the two layers are deployed together.

What does virtual patching provide for applications that cannot be patched?

Virtual patching means blocking the request that exploits a flaw at the WAF until the flaw in the code is closed. DBIR data again explains why this is critical: despite intense effort to close edge device vulnerabilities, organisations were able to fully remediate only about 54% of them over the year, and doing so took a median of 32 days (Verizon DBIR, 2025). For applications developed in-house or no longer supported by their vendor, that period is usually even longer.

FortiWeb integrates with leading vulnerability scanners such as Acunetix, HP WebInspect, IBM AppScan, Qualys, ImmuniWeb and WhiteHat; the vulnerabilities the scanner finds are automatically converted into security rules and the application stays protected until the development team fixes the code (Fortinet FortiWeb Data Sheet, 2025). When the application itself needs to be overhauled, we run the patching plan on the same calendar together with our custom web and backend development team.

What does the machine learning layer change in a WAF?

The short answer: it catches deviations that have no signature and reduces the false positive burden. FortiWeb's first line of defence consists of the classic WAF engines. Traffic that passes this layer is compared against the application's continuously updated behaviour model; a Support Vector Machine (SVM) using vector patterns from FortiGuard Labs separates anomalies into "benign deviation" and "attack" (Fortinet FortiWeb Data Sheet, 2025).

The practical meaning of that distinction is this: a user who accidentally types extra characters into a form field and an attacker who writes a database query into the same field are both "anomalies" according to the model; but only the second is blocked. Automatic learning approaches that treat every anomaly as a threat produce a large number of false blocks. The outcome in the field is well known: the administrator loosens the rules, the WAF effectively turns into a monitoring tool, and its blocking capability remains theoretical.

An honest caveat is needed here. The phrase "nearly 100% accuracy" that appears in Fortinet's data sheet is not an independent laboratory measurement but a qualitative vendor claim; it should not be treated as a statistic. The correct method is to first run FortiWeb WAF in learning and observation mode with your own production traffic, review the model generated and the rules triggered, and then move gradually into blocking mode. At Sora Yazılım we follow this order in deployment projects and make the move to blocking mode with the approval of the team that owns the application.

How does FortiWeb discover and protect APIs?

FortiWeb's API discovery works automatically with machine learning: application traffic is continuously evaluated to produce an inventory of the endpoints in production, and a positive security model is built on that inventory. When the organisation uploads its own schema definition — OpenAPI, XML and generic JSON are the supported schema formats — calls that do not conform to the schema are rejected, and by integrating schema validation into the CI/CD pipeline the policy refreshes itself every time the API is updated (Fortinet FortiWeb Data Sheet, 2025).

Together, these two capabilities answer the two hardest problems in enterprise API security. The first is shadow APIs: endpoints that are undocumented, invisible in the inventory, yet exposed to the internet. Traffic-based discovery makes them visible. The second is the inability of security policy to keep up with development speed; binding schema validation to the build pipeline makes policy a part of the release cycle. FortiWeb also offers XML and JSON protocol conformance checking, web service signatures and API gateway functionality; the backend services of mobile applications are protected within the same policy set.

In container-based microservice architectures, where to place the protection point is a separate design decision. Whether a single inspection point in front of the ingress is required or a separate policy per service group is needed is something we determine within the scope of our DevOps and infrastructure service, by examining your existing deployment pipeline.

How is bot traffic separated and managed?

FortiWeb combines machine learning with threshold-based detection, bot deception and biometric behaviour analysis to distinguish human users, good bots and bad bots from one another; where necessary it applies CAPTCHA and Real Browser Enforcement. The targeted attack types include automated bot traffic, web scraping, crawler bots, data harvesting and credential stuffing (Fortinet FortiWeb Data Sheet, 2025).

Good bot recognition matters more than people assume on the e-commerce and publishing side: a rule that accidentally blocks search engine crawlers can cause a far greater loss of visibility than the security gain it delivers. With advanced tracking techniques, FortiWeb distinguishes human requests, automated requests and repeat attackers over time; thanks to the FortiView bot dashboard and the OWASP Top 10 attack classification, the team can report which traffic was blocked and why. On the credential stuffing side, the FortiGuard Credential Stuffing Defense subscription compares login attempts against FortiGuard's list of compromised credentials, and different actions ranging from alerting to blocking can be defined.

The scope boundary must also be drawn clearly. FortiWeb provides application layer DoS prevention and layer 4 stateful network firewall functionality; however, volumetric DDoS that saturates the link requires an upstream carrier or scrubbing service. In ENISA's 2025 report, DDoS attacks stood out as the most common threat type across the EU and affected more than one sector at a rate of 81.4% (ENISA, 2025); application layer protection and volumetric protection must therefore be planned separately.

Which PCI DSS 4.0 requirements does FortiWeb meet?

Three requirements directly: 6.4.2, 6.4.3 and 11.6.1. PCI DSS v4.0 mandates in 6.4.2 that an automated technical solution be deployed in front of public-facing web applications to continuously detect and prevent web-based attacks, and defines this requirement as a "best practice" until 31 March 2025 and mandatory thereafter (PCI SSC, PCI DSS v4.0, 2022). The same date applies to 6.4.3. The table below summarises how these requirements map onto FortiWeb.

FortiWeb Client-Side Protection continuously detects and blocks malicious and unauthorised JavaScript running in the user's browser; it protects the payment page against attacks such as formjacking, Magecart and online card skimming. Fortinet positions this function as directly aligned with requirements 6.4.3 and 11.6.1 of PCI DSS 4.0 (Fortinet FortiWeb Data Sheet, 2025). It should also be added that compliance is not completed with a product: FortiWeb WAF meets the technical control the auditor asks about; scoping, policy documentation and penetration testing are separate line items.

Which FortiWeb model and deployment form should be selected?

The choice is determined by two variables: the volume of HTTPS traffic to be inspected and the deployment preference. The FortiWeb WAF hardware family scales from 100 Mbps to 70 Gbps and latency is below 5 milliseconds on all models; on the 600F and higher models SSL/TLS processing is performed in hardware (Fortinet FortiWeb Data Sheet, 2025). In scenarios where encrypted traffic will be terminated, this distinction is the most decisive technical criterion in the selection.

All values in the table are "up to" figures measured by Fortinet under ideal laboratory conditions and vary with system configuration; real capacity depends on the security profiles enabled and the SSL termination load. On all hardware models the application licence is unlimited, Active/Passive and Active/Active clustering are supported, and a Trusted Platform Module (TPM) is included. One point needs to be underlined: Fortinet does not publish disaggregated metrics for FortiWeb (such as IPS throughput or SSL inspection throughput) as it does in the FortiGate data sheets; the table contains a single total throughput row. Comparison between models is therefore made on a single value, and capacity planning rests on an expected rather than a measured ceiling. In practice the correct method is this: extract the real requests per second and the number of concurrent connections from your existing load balancer or web server logs, decide whether SSL termination will happen on FortiWeb or on the servers behind it, and select the model according to these two inputs. Of two deployments in the same throughput class, one can consume noticeably more resources than the other purely because of the TLS key exchange load and the cipher suite choice; that difference does not appear in the data sheet table.

What do the virtual, container and SaaS options offer?

FortiWeb-VM versions carry the same feature set as the hardware models and are licensed at five levels from 1 vCPU to 16 vCPU; the HTTP throughput values are 25 Mbps, 100 Mbps, 500 Mbps, 3 Gbps and 6 Gbps respectively. Recommended memory ranges from 8 GB to 64 GB, and the number of administrative domains is between 4 and 64 depending on the memory allocated. The supported hypervisors are VMware, Microsoft Hyper-V, Citrix XenServer, open source Xen, VirtualBox, KVM and Docker; on the public cloud side it can be used as a virtual machine on AWS, Azure, Google Cloud and Oracle Cloud, or as WAF as a service (Fortinet FortiWeb Data Sheet, 2025).

The container versions (FWB-VMC01–VMC08) run with the Docker container manager; the smallest level starts at 25 Mbps HTTP throughput. There is an internal inconsistency in the data sheet here, and it is more honest to state it than to hide it: for the top level, VMC08, the performance table says 3 Gbps while the ordering information section says 2 Gbps. In a design where the upper limit is decisive, we confirm this value in writing with Fortinet before ordering. For the container versions, a minimum of 4 GB and a recommended 8 GB of memory and storage between 30 GB and 500 GB are listed; high availability support, however, is not listed, so the availability architecture must be planned at the orchestration layer. For managing multiple FortiWeb devices from a single point, the FortiWeb Central Manager licence is offered with 10-device or unlimited-device options.

How is FortiWeb positioned in the network?

There are five deployment options: Reverse Proxy, Inline Transparent, True Transparent Proxy, Offline Sniffing and WCCP (Fortinet FortiWeb Data Sheet, 2025). Reverse Proxy is the most common mode; because FortiWeb terminates the connection, application delivery functions such as URL rewriting, content routing, layer 7 server load balancing, HTTPS/SSL offloading, HTTP compression and caching can be used in this mode. Inline Transparent and True Transparent Proxy modes provide inline inspection without changing the IP addressing plan; they are preferred in environments where touching the existing architecture would be costly.

Offline Sniffing mode only monitors traffic from a mirror (SPAN) port and does not block. It is a useful first step for pre-deployment assessment, measuring the existing attack surface and maturing the machine learning model with production traffic. WCCP mode, in turn, allows traffic to be redirected to FortiWeb from an upstream device (typically a FortiGate).

How does FortiWeb fit into existing infrastructure and Turkey's compliance requirements?

FortiWeb is positioned not as a standalone box but as a component of the Fortinet Security Fabric. Integration with FortiGate and FortiSandbox enables in-depth analysis of suspicious file uploads and the sharing of information about compromised internal resources; quarantined IP information is passed between devices. According to Fortinet's own statement, the Security Fabric ecosystem covers more than 500 third-party solutions (Fortinet, 2026) and FortiGuard Labs processes and analyses more than 100 billion events per day (Fortinet, 2026). For the FortiGuard antivirus engine that FortiWeb uses in file upload scanning, Fortinet states that 1.8 million new definitions are produced weekly (Fortinet FortiSASE Data Sheet, 2026).

On the FortiGuard side there are five separate subscription options for FortiWeb: the IP reputation service, FortiWeb Security Service (application layer signatures, machine learning threat models, malicious robot lists, suspicious URL patterns and web vulnerability scanner updates), Credential Stuffing Defense, cloud sandbox and antivirus. Which subscriptions are needed varies with the nature of the protected application; in an application that takes payments, credential stuffing defence and file upload scanning are usually planned together. Phishing pressure arriving by email should also be included in the same picture; at that layer FortiMail plays a complementary role, and on the endpoint side FortiEDR does the same. If remote teams' access to internal applications needs to be managed on an identity basis, this is evaluated together with FortiSASE.

What should be considered in terms of KVKK and local operations?

The Personal Data Security Guide of KVKK, Turkey's data protection authority (Technical and Administrative Measures, January 2018), defines firewalls and gateways as the "first line of defence" against unauthorised access threats arriving from the internet, and in its summary table of technical measures it lists application security, intrusion detection and prevention systems, log records and penetration testing as separate items alongside network security (KVKK, 2018). The absence of an inspection layer in front of a public-facing application that processes personal data means that the application security item in that table effectively remains empty.

Three topics stand out on the operational side. The first is where the records will be kept: when FortiWeb events are exported to a FortiAnalyzer located in Turkey, both the retention period and data residency stay under control. The second is the timetable for moving into blocking mode; in a production application, a false block can cause business loss faster than an attack. The third is binding WAF policy to the application release cycle — when a new endpoint goes live, the policy must be updated as well. As a Fortinet authorised channel partner, we handle licensing, deployment, migration from an existing WAF and the managed service side with Turkish-language support; for other Fortinet components see our Fortinet solution family, and for the full portfolio our solutions page.

To choose the right FortiWeb WAF model, you first need to clarify the number of applications to be protected, the volume of HTTPS traffic to be inspected, the PCI DSS scope and the deployment preference (hardware, virtual machine, container or SaaS). Once you share your current application inventory and traffic profile, we work out the appropriate model, subscription set and deployment plan together, and prepare a quote covering hardware, licence and managed service line items. Contact us through our contact page for an assessment call and a quote.