What a Web Application Firewall Actually Blocks (and What It Can\can't)

A traditional network firewall controls traffic according to network-level rules, such as IP addresses, ports and protocols. A WAF focuses on web application traffic, inspecting HTTP requests and applying rules designed to identify potentially malicious activity.

Depending on its deployment and configuration, a WAF may operate at the hosting server, reverse proxy, content delivery network (CDN) or another point in front of the application.

When a request matches a blocking rule, the WAF can reject it before it reaches the application server. Other requests may be logged, challenged or allowed through for further processing.

A WAF can therefore reduce the number of hostile requests that reach your website, but its effectiveness depends on the rules, traffic visibility, deployment architecture and ongoing maintenance.

2. What a WAF Can Block or Help Reduce

<box gap={3}>
<row align="start" gap={3}>
<AsyncImage query="cybersecurity SQL injection code on computer terminal" aspectRatio="4:5" maxWidth="112px" radius="lg" />
<box flex="1" gap={1}>
**SQL injection attempts**

  SQL injection involves attempts to manipulate database queries through application inputs. WAF rules can identify and block many common attack patterns in query parameters, forms and other requests. However, a WAF cannot guarantee protection against every injection technique.
</box>

</row>
<divider color="subtle" />
<row align="start" gap={3}>
<AsyncImage query="cross site scripting XSS cybersecurity web browser code illustration" aspectRatio="4:5" maxWidth="112px" radius="lg" />
<box flex="1" gap={1}>
**Cross-site scripting (XSS)**

  XSS attacks attempt to inject malicious scripts into web pages viewed by users. A WAF can block many known payloads, but application-level output encoding, input handling and secure coding remain essential.
</box>

</row>
<divider color="subtle" />
<row align="start" gap={3}>
<AsyncImage query="automated bot traffic cybersecurity login page server protection" aspectRatio="4:5" maxWidth="112px" radius="lg" />
<box flex="1" gap={1}>
**Suspicious automated traffic**

  Rate limits, bot-management rules and behavioural signals can help reduce repeated login attempts, abusive requests and automated scanning. More sophisticated bots may evade simple rules, and legitimate users can sometimes be misclassified.
</box>

</row>
<divider color="subtle" />
<row align="start" gap={3}>
<AsyncImage query="website security vulnerability scanner dashboard computer screen" aspectRatio="4:5" maxWidth="112px" radius="lg" />
<box flex="1" gap={1}>
**Requests targeting known vulnerabilities**

  Managed rule sets can recognise patterns associated with common web vulnerabilities and known exploit attempts. This can reduce exposure while a patch is being prepared, but it should never become a reason to delay updates.
</box>

</row>
</box>

Other protections a WAF may provide

Depending on the product, configuration and subscription, a WAF may also help with:

• HTTP protocol abuse and malformed requests.

• IP reputation filtering.

• Request rate limiting.

• Virtual patching for selected known vulnerabilities.

• Security logging and alerts.

• Custom rules for specific application routes or request patterns.

Not every WAF includes every feature. Check the actual product specifications before assuming a particular capability is available.

3. What a WAF Cannot Reliably Prevent

Understanding the limitations of a WAF is just as important as understanding its coverage.

A WAF can lower risk, but it cannot make an insecure application secure by itself.

4. Why Software Updates Still Matter

A WAF may recognise some exploit attempts against vulnerable software, but it does not remove the vulnerability.

Consider a WordPress plugin with a known security flaw. A WAF might block requests matching a rule designed to detect exploitation. However, an attacker may use a different request pattern, or the rule may not cover the specific weakness.

The correct response is to update the plugin, replace it if it is no longer maintained, or disable and remove it when necessary.

Use the WAF as an additional barrier while you address the underlying issue, not as a substitute for maintenance.

For practical steps, follow the WordPress hardening checklist.

5. Why Protecting the Origin Server Matters

A WAF can only inspect traffic that passes through it.

In a reverse-proxy or CDN deployment, the origin server may have a public IP address that attackers can discover through DNS history, exposed configuration, other services or previous records. If that server accepts direct web requests from untrusted sources, an attacker may be able to bypass the WAF.

How to reduce origin bypass risk

• Configure the origin firewall to accept web traffic only from the WAF or proxy infrastructure where practical.

• Confirm that the application does not expose an alternative public endpoint.

• Restrict administrative access separately from public website traffic.

• Review DNS records and other services that could reveal or expose the origin.

• Preserve the ability to access the server securely for maintenance and incident response.

• Test that legitimate traffic still works after access restrictions are introduced.

Do not block all inbound traffic without checking your hosting setup. Some services, monitoring systems or administrative connections may require separate access rules.

Origin restrictions also depend on the deployment model. A WAF integrated directly into the hosting server may require a different configuration from a cloud-based reverse proxy.

6. How to Deploy a WAF Without Breaking Your Website

An overly restrictive firewall can block legitimate customers, prevent forms from submitting or disrupt an online checkout. A controlled rollout helps reduce these problems.

Step 1: Identify what needs protection

List your public website routes, login endpoints, forms, APIs and sensitive application functions. Identify any services that must communicate with the website.

Step 2: Review the available rules

Understand which protections are enabled, how requests are evaluated, and what logging or exception controls the product provides.

Step 3: Start with detection or monitoring mode

If the product supports a detection-only mode, use it to observe which requests would trigger rules without immediately blocking them.

Review the results against normal website activity. The appropriate observation period depends on traffic volume and the criticality of the application; a week may be a useful starting point, but it is not a universal requirement.

Step 4: Move to enforcement gradually

Enable blocking after reviewing expected traffic and addressing likely false positives. Where possible, introduce stricter controls in stages and test critical functions after each change.

Step 5: Investigate false positives carefully

If a legitimate request is blocked, identify the specific rule and affected route. Use the narrowest suitable exception rather than disabling an entire rule set.

Step 6: Review logs and alerts

Monitor blocked requests, repeated attack patterns, changes in traffic and unusual activity. Set up alerts for events that need timely attention.

Step 7: Reassess after application changes

New plugins, website features, API endpoints and deployment changes can alter normal traffic. Recheck firewall behaviour after significant updates.

7. Combine a WAF With Other Security Layers

A resilient security setup uses multiple controls because each addresses a different category of risk.

<box border radius="xl" padding={3} gap={3}>
<row align="start" gap={3}>
<box background="surface-secondary" radius="lg" size="40px" align="center" justify="center">
<icon name="shield-check" size="xl" />
</box>
<box flex="1" gap={1}>
**WAF and traffic filtering**

  Inspect requests and block traffic that matches applicable security rules.
</box>

</row>
<divider color="subtle" />
<row align="start" gap={3}>
<box background="surface-secondary" radius="lg" size="40px" align="center" justify="center">
<icon name="refresh-cw" size="xl" />
</box>
<box flex="1" gap={1}>
**Patching and secure configuration**

  Fix known vulnerabilities, remove unused software and restrict permissions.
</box>

</row>
<divider color="subtle" />
<row align="start" gap={3}>
<box background="surface-secondary" radius="lg" size="40px" align="center" justify="center">
<icon name="database" size="xl" />
</box>
<box flex="1" gap={1}>
**Off-site backups**

  Preserve a recovery path if data is damaged, deleted or compromised. Test restoration rather than relying on backup status alone.
</box>

</row>
<divider color="subtle" />
<row align="start" gap={3}>
<box background="surface-secondary" radius="lg" size="40px" align="center" justify="center">
<icon name="activity" size="xl" />
</box>
<box flex="1" gap={1}>
**Monitoring and incident response**

  Detect unusual behaviour, investigate alerts and respond when preventive controls are insufficient.
</box>

</row>
</box>

You can review the SteboHost backup options and build a recovery plan appropriate for your website.

8. How to Know Whether Your WAF Is Working

A high number of blocked requests does not necessarily mean your website is safer, and a quiet log does not automatically mean that no attacks are occurring.

Evaluate a WAF using a combination of security and operational indicators:

• Are rules blocking relevant malicious test requests?

• Are critical application functions still working?

• Are legitimate customers encountering unexpected blocks?

• Are alerts reaching the right person?

• Are direct requests to the origin restricted where required?

• Are the rules and signatures being maintained?

• Are known vulnerabilities still being patched?

• Can the team investigate an alert and recover from an incident?

Use controlled testing in a staging environment whenever possible. Avoid testing exploit payloads against systems you do not own or have permission to assess.

Review logs on a schedule that fits the site's risk and traffic volume. Monthly reviews can help identify recurring patterns for a small website, but high-risk applications may need more frequent monitoring and alerting.

Frequently Asked Questions

Does a WAF block all hackers?

No. A WAF can block many requests that match known attack patterns, but it cannot reliably stop every exploit, stolen credential, application logic flaw or attack that bypasses the firewall.

Can a WAF protect an outdated WordPress plugin?

It may block some attempts to exploit a known vulnerability, depending on the rules and the attack. However, it does not fix the vulnerable plugin. Updating, replacing or removing the affected component remains necessary.

Does a WAF improve website performance?

It can reduce application workload when malicious requests are blocked before reaching the origin server. However, the overall performance effect depends on the WAF's architecture, configuration, caching and processing overhead.

Should a small business use a WAF?

A WAF can be useful for public websites, online stores and applications exposed to internet traffic. The best option depends on the website's risks, hosting architecture, available budget and the features provided by the service.

Is a WAF enough to secure an online store?

No. An online store also needs secure payment integration, software maintenance, strong administrator authentication, appropriate permissions, tested backups and monitoring.

What is the difference between a WAF and a traditional firewall?

A traditional network firewall primarily controls network traffic according to addresses, ports and protocols. A WAF focuses on web application requests and applies rules designed to identify potentially malicious HTTP and HTTPS traffic.

Conclusion

A web application firewall is a valuable security layer, but it is not a complete security strategy. It can help block SQL injection attempts, cross-site scripting payloads, suspicious automated traffic and requests targeting known vulnerabilities. Its effectiveness depends on configuration, visibility and maintenance.

It cannot repair vulnerable software, reliably stop every attacker using valid credentials, restore deleted data or protect traffic that bypasses it.

For stronger protection, combine a WAF with prompt patching, secure access controls, origin restrictions, tested off-site backups and active monitoring.

Explore SteboHost hosting services and verify the security options available for your chosen plan before deploying a WAF.