Unfortunately, security scans are frequently launched against a website or web application sitting behind a web application firewall, or some other kind of web security gateway device. A website audit performed for a website through a “man in the middle” device or software, will only give a false sense of security.

First and most importantly of all, one would be scanning the web farm’s perimeter network and not the website itself. Therefore if the scope is to secure a website, this is not the right approach. If the target website is vulnerable to a SQL injection attack, a web application firewall sitting in front of the website might block the scanner’s requests, resulting in the vulnerability not being discovered and reported.

Some might also argue that there is no need to scan a website when there is a WAF sitting in front of it. After all, it’s from where the attacker has to go in, right? As a rule of thumb, security is as weak as your weakest point on the network. Apart from that, there are a number of other reasons why one still has to scan and audit his website directly, and not through its perimeter network, or nothing at all.

As we’ve seen in the past, web application firewalls can be exploited and bypassed with a number of freely available tools and scripts. For a malicious user, bypassing a perimeter network and finding an insecure web application is like discovering a hidden treasure. It will only take him a couple more minutes until he gains control over the website, the web server, and penetrates deeper into the corporate network.

A web application firewall will only delay attacks, and should not be used as a standalone security solution, as recommended by a number of web application firewall vendors themselves. Usually a web application firewall is used to help beef up the security of the perimeter network, but never as a website or web application audit replacement. If the budget permits, it is always a good practice to install one. New attack vectors are frequently discovered, and unless your web application is properly secured, your application can still be hacked, even if it is sitting behind a web application firewall.

A web application should always function as it was intended to function. Simple isn’t it? E.g. if the “Send Email” button in a web form is clicked, and by mistake an email is sent to support@acunetix.com, instead to sales@acunetix.com, then there is a problem which needs to be fixed. A web vulnerability is a website malfunction, a problem which has to be fixed, always!

Therefore if the scope of the penetration test or web security audit is to secure a website or web application, the security scan must always be launched directly against the target, without any ‘man in the middle’ device or software. The best practise, as always, is to tackle the problem at source, and not trying to hide it or delay its consequences. In this case then, one should always secure the web application itself.

As you said there are pros and cons of scanning through WAF and it is up to the customer to decide which is the “right” approach.

Though what we are suggesting in our post is that if the client’s target is to secure the web application itself, then he should scan it directly. If time permits and one has a WAF installed, ideally he should scan the website directly to secure it, and then scan the perimeter network, to make sure the whole infrastructure is secured.

Also, as the post concludes, having a secure web application is always the safest, after all, vulnerabilities are normal software bugs which should be addressed and fixed.

As you’ve said yourself the SaaS discovered vulnerabilities which were not stopped from the WAF. So what if the hacker found these security holes before the SaaS did? As you can see the importance of a securing the web application itself is always a top priority.

Again, like we concluded in the blog post, we are emphasizing on the importance of properly securing the web application itself, and tackle the problem at source.