Block attacks against web applications and APIs to reduce the risk of your public-facing services being breached or knocked offline. We assess where protection should sit based on traffic source and system location, and handle planning, build, migration, training, and annual maintenance.
Public-facing websites, app back ends, and APIs are the one place a business must leave open to everyone. A firewall can block connections that should not get in. But a malicious request that walks in the front door looking completely normal is something it cannot stop.
Malicious commands are inserted into an input field, tricking the application into executing them, reading out the database, or injecting a malicious script. It travels over a normal HTTPS channel, so a firewall sees nothing unusual.
A flood of hijacked devices arrives at once. The network layer (L3/L4) that overloads the link and the application layer (L7) that targets the application require different handling.
Ticket-scalping scripts, price-comparison scrapers, and credential stuffing that tries stolen username/password pairs one by one. The requests are formatted correctly; they just don't behave like a human.
Most businesses cannot say exactly how many APIs they expose externally. An old version left callable after a redesign is the quietest leak of all.
The checkout page loads third-party JavaScript. If even one script is tampered with, card numbers are copied out at the moment of submission. The site itself shows no unusual log entries.
These three terms often get lumped together, but they sit in different places and do completely different jobs. Thinking of your IT system as a building makes it easy to follow.
It asks: can this person enter the building? The answer is based on source address, port, and protocol. The problem is that a public website has to keep port 443 open to everyone. As long as a visitor walks in through the front door normally, the guard has no grounds to stop them.
Once the guard lets someone in, the WAF reads everything the visitor writes down, word by word. It understands the language of web applications, so it can tell that the "name" field contains not a name but a command meant to steal data from the database. A firewall cannot read this layer; to it, that's just correctly formatted web traffic.
A copy of the content is placed at the branch closest to the customer, so the customer doesn't have to travel to headquarters. It solves "how fast", not "how safe". But because every customer passes through a branch first, that branch becomes the ideal place to put a checkpoint. That's why cloud-based WAFs mostly live on a CDN.
A firewall controls who can come in. A WAF controls what they bring in. A CDN controls how far the customer has to travel. The three play different roles and cannot substitute for one another.
A fuller plain-language explanation: What is a WAF? How do firewall, WAF, and CDN differ?
The industry packages the first four items into one term: WAAP (Web Application and API Protection), that is, WAF, DDoS protection, bot management, and API protection. The fifth item, front-end/client-side protection, is usually procured separately, but it is equally part of what a public-facing service needs to cover.
"Which WAF should I buy" is a question a feature list can't answer. What matters is where your traffic comes from and where your systems sit.
Protection happens at the internet edge. You don't need to buy any hardware, just point your domain's DNS at Akamai. When users connect to your site, they pass through Akamai's network first, where attacks are cleaned out. Only clean, accelerated traffic reaches your servers. Suited to services with high public traffic, an unspecified broad audience, high downtime costs, or overseas users who need acceleration.
Related products: App & API Protector, Prolexic, Bot Manager, Akamai API Security, Client-Side Protection & Compliance.
The appliance sits in your own data center; traffic never leaves. It already functions as the load balancer in front of your servers (an ADC, Application Delivery Controller), and the WAF is a module on that same box. You can add protection without changing your network architecture, so one purchase solves both "staying up" and "staying unbreached". Suited to organizations with data-residency requirements, audit requirements for controllable traffic, or an existing BIG-IP® ADC that they want to add protection to.
F5 Distributed Cloud and F5 WAF for NGINX®, which deploys alongside containers, are also available.
Available as hardware, virtual machine, container, or cloud SaaS (FortiAppSec Cloud, formerly FortiWeb Cloud), so it can sit directly in your data center or cloud environment. FortiWeb has its own management console and can also join the Fortinet Security Fabric. Logs are sent to FortiAnalyzer for centralized analysis and audit reporting. Suited to mid-sized businesses, internal and B2B systems, or organizations already on the Fortinet platform that want logs and audit reports centralized in one system.
All three can coexist. A common architecture has Akamai absorbing large-scale attacks at the outer layer, with F5 or FortiWeb serving as the last line of defense inside the data center. Selection depends on traffic scale, data center conditions, compliance requirements, and existing equipment; each requirement maps to one primary recommendation. See the decision logic in How to choose a WAF: three scenarios compared; for each vendor's product line, see the Akamai, F5, and Fortinet brand pages.
We source vendor products and support through authorized channels in Taiwan, and provide planning, deployment, migration, training, and annual maintenance services.
Besides blocking "traffic coming in", another position that often gets overlooked is "queries going out".
Once malware is planted on an internal computer, its first step is usually to connect back to the attacker's command server. That step always requires a DNS query first (resolving a domain name to an IP address). URMAZI SENTRY (PDNS, Protective DNS) sits at exactly this checkpoint. It can work alongside your existing DNS servers or replace them outright, running entirely in-house:
Deployment can start in TAP (passive) mode, mirroring DNS traffic for observation without touching the existing architecture. Once confirmed, it switches to inline mode to block actively. This layer complements a WAF; it does not replace one.
Which regulations and which tier actually apply depends on your organization's business and the determination of the competent authority. During deployment, we map to the regulatory requirements that apply to your organization and provide configuration records and reports as audit evidence.
A WAF is not a product you buy, switch on, and you're done. The real cost lies in "tuning it so it doesn't block your own users" and "keeping up with updates". Both are part of delivery and maintenance.
Yes. A firewall decides whether a connection is allowed in. Port 443 on a public-facing site has to stay open. Attacks against web applications travel through that same port, so a firewall lets them through as normal traffic. A WAF checks what the traffic actually contains. The two operate at different layers and cannot substitute for each other.
False positives are the most common failure mode for traditional WAFs. The approach is to run in detection mode for a period, tune out false-positive rules, then enable blocking in stages. Rules are reviewed again whenever the site is redesigned; this is one of the main tasks in annual maintenance.
Yes. Cloud edge protection works by routing traffic through the vendor's global network first. If you have data-residency requirements or need auditable traffic, you should first evaluate an on-premises option. You can also route only public website traffic through the cloud and keep sensitive systems on-premises.
For cloud-based options, the cutover point is DNS, which can usually be done off-peak without downtime. On-premises appliances need a scheduled maintenance window for cutover. Timeline mainly depends on rule tuning; installation itself has little impact.
Each requirement maps to one primary recommendation. The proposal clearly states the reasoning behind the selection, compares it with alternatives, and notes the applicable conditions and limitations of each. If your public-facing service has no login, no payment processing, and limited API usage, the proposal will recommend deploying basic protection first, then expanding in stages as the business grows.
Leave your contact details and a description of your needs, and an engineer will get in touch to help assess architecture planning, deployment approach, and annual maintenance scope.