Web application security is often a misunderstood topic with many false beliefs held by developers and many others in the IT Industry. These beliefs can be dangerous and are telltale signs of a lack of security understanding and experience.
Popular frameworks such as Ruby on Rails and Django are written with security in mind and help developers prevent most common technical vulnerabilities, such as cross-site scripting and SQL Injection vulnerabilities.
Logical vulnerabilities are flaws in the business logic. For example by modifying the URL the attacker can make a purchase without paying. It doesn’t even end there. Many frameworks only address common issues for the default usages, so when you start doing something different they’ll fail to protect against even simplest issues such as DOM XSS (
Therefore when using web frameworks do not solely rely on their security features and make sure you manually implement all checks that are needed and understand what they do and don’t. They don’t all just work out of the box.
This is most probably the most common misconception. You’re a startup, or a small business, who is interested in hacking your website or customer portal? Even if your company or web application itself is not of great value to an attacker, your visitors, your server's resources and the bandwidth you pay for are exactly the things that attackers are after.
Attackers do not really care who the target is. They simply use automated tools to scan large blocks of the internet and if there are vulnerable websites in such blocks they attack them. Such type of mass and
Backups can help to restore a website after it has been hacked but substituting them for good security is not a viable option. A temporarily hacked website can result in serious consequences such as: being blacklisted by search engines, having sensitive user data stolen, phishing attacks on your visitors and it will tarnish your business’ reputation.
If a website was hacked then it means that the image of the website in the backup also has the vulnerability. Hence restoring it is only a temporary solution until the attackers find the vulnerability and exploit it again.
You can never be sure that the threats won’t come from an employee or an attacker who somehow gains access to your internal network. Is the confidential data in the internal CRM or ERP that you’re working on safe from a disgruntled or curious, security savvy, employees? Not to mention the fact that the typical employee is not security savvy and is the main target in social engineering attacks. So web application security should always be catered for.
Just because people connect to your web application via a VPN, it does not mean that your application itself is secure. The same arguments I highlighted in relation to internal networks, such as disgruntled employees, network vulnerabilities and employees as victims of social engineering attacks apply in this case as well.
When configured properly, web application firewalls can help mitigate specific attacks such as the exploitation of cross site scripting and SQL injection vulnerabilities, but they won’t protect you from attacks that aren’t defined in the rules you supply them with. As explained in Getting started with Web Application Security, even though web application firewalls, or as commonly known WAFs are definitely a good addition to your security portfolio they have a number of shortcomings.
WAFs do not fix the underlying problem, they just add an additional layer of security to it to protect it. And considering there is a good number of WAFs bypass techniques which are still widely popular today, one shouldn’t solely rely on a WAF but should always fix any security flaws a web application has.
Misconceptions can be very misleading though there are no excuses. Web application security should always be catered for, and ideally at every stage of the development of the web application. There is no better way to avoid being hacked than to building a secure web application, rather than protecting your insecure code with other applications which might have their own vulnerabilities.
Emulate the malicious attackers; use automated web application security tools to identify vulnerabilities and security weaknesses in your web applications.