You check your website's security dashboard and see thousands of attacks blocked.
SQL injection attempts? Blocked.
XSS payloads? Blocked.
Suspicious bots? Blocked.
You feel pretty safe.
Then a customer reports that they can see another customer's invoice.
The WAF didn't stop it.
That raises a question I hear a lot: can a WAF prevent hacking?
Yes, a WAF can stop many attacks. But no, it can't protect your application from everything.
The difference matters because a WAF sits in front of your application and mostly makes decisions about HTTP traffic. Your application makes decisions about users, permissions, business rules, data, and what each request is actually allowed to do.
Those are two very different jobs.
Can a WAF Prevent Hacking? Only Some of It
A Web Application Firewall, or WAF, sits between the internet and your application.
A simplified request path looks like this:
User
|
v
Internet
|
v
WAF
|
v
Web Server / API
|
v
Database
When someone sends a request, the WAF can inspect things such as the URL, query parameters, HTTP method, headers, cookies, and request body.
If the request matches a malicious pattern, the WAF can block it before it reaches your application.
For example, an attacker might send a request containing a known SQL injection payload.
The WAF may recognize the pattern and reject it.
That's useful.
But the WAF doesn't necessarily understand what your application is supposed to allow.
Imagine this request:
GET /api/invoices/1043
Authorization: Bearer eyJhbGciOi...
Nothing about that request automatically looks malicious.
It's HTTPS.
It has a valid-looking token.
It's using a normal API endpoint.
The request isn't carrying an obvious SQL injection payload.
So the WAF may allow it.
But what if invoice 1043 belongs to another customer?
If your backend doesn't check ownership correctly, you've got a serious vulnerability.
The request was completely legitimate at the HTTP level.
The problem was authorization.
OWASP continues to rank Broken Access Control as the top category in its Web Application Security Risks list. That includes problems such as accessing another user's records, missing authorization checks on APIs, and privilege escalation.
A WAF can't magically fix that.
What a WAF Is Actually Good At
A WAF is still extremely useful.
The mistake is expecting it to do the job of your entire security program.
A properly configured WAF can help protect against common web attacks such as:
- SQL injection
- Cross-site scripting
- Malicious request payloads
- Some path traversal attacks
- Common exploit patterns
- Automated malicious traffic
- Certain bot attacks
- Request flooding and rate-abuse patterns
- Some known vulnerability exploitation
It can also provide a layer of protection while you work on a permanent fix.
This is sometimes called virtual patching.
For example, imagine a popular plugin has a newly discovered vulnerability and your team needs a few days to test and deploy the official patch.
A WAF rule may be able to block the specific attack pattern during that window.
That's valuable.
But notice the wording.
During that window.
The WAF isn't fixing the vulnerable code.
It's putting another barrier in front of it.
That's a very different thing.
A good WAF also gives you visibility into what's hitting your application. Instead of seeing only "something attacked my website," you can start seeing patterns:
POST /login
POST /login
POST /login
POST /login
GET /admin
GET /wp-login.php
GET /api/users
That information can help you identify attack campaigns, abusive clients, and endpoints that deserve closer investigation.
Why a Valid Request Can Still Hack Your App
This is where many WAF setups fall short.
Attackers don't always send obviously malicious requests.
Sometimes they send completely normal requests in the wrong sequence.
Consider an e-commerce API:
GET /api/orders/7812
Authorization: Bearer <valid-token>
The WAF checks the request.
The token exists.
The URL looks normal.
The method is normal.
No obvious attack payload exists.
Request allowed.
But the application should have asked:
> Does this user actually own order 7812?
If the backend forgot that check, the attacker can potentially change the order number:
GET /api/orders/7813
Authorization: Bearer <valid-token>
And then:
GET /api/orders/7814
Authorization: Bearer <valid-token>
If those orders belong to other customers and the API returns them, you've got a broken access control problem.
This type of vulnerability is often called BOLA, or Broken Object Level Authorization. It's especially relevant to APIs because the attacker may not need to break authentication at all.
They already have a valid account.
They're simply accessing something they shouldn't.
A WAF usually has no idea which customer owns which database record.
Your application does.
That's why a security system that only asks "Does this request look malicious?" will miss attacks where the request itself is valid but the action isn't authorized.
Zero-Days, Logic Bugs, and Other Things a WAF Can Miss
There are other situations where a WAF isn't enough.
Business logic flaws
Suppose your application gives users a $10 discount code.
The intended rule is:
> One discount per customer.
But the developer forgot to enforce that rule on the server.
An attacker can apply the same discount 100 times.
There may be nothing malicious in the HTTP request.
The attack is abusing how the application works.
A WAF isn't a business analyst.
It doesn't know that the discount should only work once.
Authentication and authorization bugs
If your API accidentally allows a normal user to call an administrator endpoint, a WAF may not notice.
The request could look perfectly normal:
POST /api/admin/export-users
Authorization: Bearer <valid-user-token>
Content-Type: application/json
The problem is not the HTTP request.
The problem is that the server accepted the wrong user's permission.
Unknown vulnerabilities
WAF rules are usually built around known attack patterns and behaviors.
A brand-new vulnerability can behave differently.
If there isn't an appropriate rule, the WAF may have nothing useful to block.
That's one reason patching remains critical.
Verizon's 2026 Data Breach Investigations Report found that vulnerability exploitation accounted for 31% of breaches, making it the leading initial access vector in its analysis.
A WAF can reduce exposure to some exploitation attempts.
It shouldn't become an excuse to leave vulnerable software running.
Encrypted traffic
Modern websites use HTTPS, which means traffic is encrypted between the client and the point where TLS is terminated.
A WAF needs access to the HTTP request at the appropriate point to inspect it.
If the architecture isn't configured correctly, the WAF may have limited visibility into what the application is actually receiving.
This is one reason security architecture matters just as much as enabling a feature called "WAF."
WAF vs Vulnerability Scanner: They're Not the Same Thing
One of the easiest ways to understand this is to stop thinking of security tools as interchangeable.
ToolMain jobExampleWAFFilter live web trafficBlock a SQL injection patternVulnerability scannerFind weaknessesDetect vulnerable software or exposed servicesCode scannerFind problems before deploymentIdentify insecure code patternsBrowser testingTest real application behaviorCheck login and user workflowsMonitoringDetect operational/security changesSSL expiry, uptime, unexpected changes
A WAF protects the front door while traffic is arriving.
A vulnerability scanner looks for weak points that need fixing.
Code scanning looks at what you're about to deploy.
Browser testing checks what users can actually do.
Monitoring helps you notice when something changes or breaks.
You need different layers because attackers don't use only one type of attack.
If your website has a vulnerable plugin, the answer isn't simply "turn on the WAF."
The answer is to patch the plugin.
If your API exposes another user's data, the answer isn't "add another WAF rule."
The answer is to fix authorization.
If someone is sending thousands of login attempts per minute, a WAF or rate-limiting layer can be extremely useful.
Different problem.
Different control.
How I'd Use a WAF Without Fooling Myself
If I were responsible for a production website today, I'd treat the WAF as one layer in a larger process.
Here's the order I'd use.
1. Keep the application patched
Update your CMS, frameworks, plugins, libraries, and server software.
Remove software you don't actually use.
Don't leave an old component online simply because "the WAF blocks attacks against it."
2. Scan the application
Look for known vulnerabilities, exposed services, security misconfigurations, outdated components, and suspicious endpoints.
A scan gives you something a WAF can't: a list of weaknesses you need to investigate.
3. Put a WAF in front of public applications
Use it to filter common attacks, control abusive traffic, and add another layer between attackers and your application.
But don't stop there.
4. Test authorization
Create two normal accounts.
Then test whether account A can access account B's objects.
Try changing:
/users/1001
/users/1002
/orders/4501
/orders/4502
/invoices/1043
/invoices/1044
Do this against your own application and test environment.
Authorization bugs are often invisible to a basic WAF.
5. Watch what the WAF is blocking
Don't just enable it and forget about it.
Look at blocked requests.
Look for repeated attacks.
Look for endpoints being targeted.
Look for false positives that may be breaking legitimate users.
A WAF that blocks everything isn't a good WAF.
A WAF that allows everything isn't useful either.
6. Test your application separately
Try the things a WAF isn't designed to understand.
Can a normal user access an admin function?
Can one user read another user's data?
Can a password reset token be reused?
Can a discount be applied repeatedly?
Can an uploaded file become executable?
Can an API return fields the current user shouldn't see?
Those questions are about application behavior, not just traffic filtering.
So, Is a WAF Worth It?
Absolutely.
Just don't confuse protection with security.
A WAF can make attacks harder.
It can block common payloads.
It can slow down automated abuse.
It can provide virtual patches for some vulnerabilities.
It can give you useful visibility.
But it won't look at your database and understand that invoice 1043 belongs to Alice, not Bob.
It won't automatically know that a normal user shouldn't call /api/admin/export-users.
It won't fix an insecure password-reset flow.
It won't repair vulnerable application code.
And it won't guarantee that a new attack technique will match an existing rule.
That's why the better question isn't:
> "Do I have a WAF?"
Ask:
> "What happens if the WAF misses the attack?"
That's where your other security layers matter.
If you want to see what your public-facing website exposes before an attacker finds it, you can run a free scan and start with the obvious weaknesses. For a broader security workflow, you can also review the Torlyx security features.
Then fix what the scan finds.
That's the part a WAF can't do for you.
FAQ
Can a WAF stop all cyber attacks?
No. A WAF can block many common web attacks and suspicious requests, but it can't reliably detect every authorization flaw, business logic bug, zero-day, or vulnerable application component. It should be treated as one security layer, not complete protection.
Does a WAF replace vulnerability scanning?
No. A WAF filters traffic while a vulnerability scanner looks for weaknesses in your website and infrastructure. Using both gives you protection during attacks and visibility into problems that need fixing.
Is a WAF worth it for a small website?
It can be, especially if the site handles logins, customer data, payments, or public APIs. But basic patching, strong authentication, correct authorization, backups, and regular security checks should come before assuming a WAF makes the site secure.