7 Common Web Application Development Security Misconceptions

Are you a web application developer? How familiar are you with web application security? Read through these seven common web application development security misconceptions to make sure you don't fall for the trap and ensure you always cater for web application security in your work.

This is an archive post from the Netsparker (now Invicti) blog. Please note that the content may not reflect current product names and features in the Invicti offering.

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.

Common misconceptions in web application developmentWeb application developers in particular should be aware of these common misconceptions. Apart from writing the code developers are typically involved in the design stages of web applications, during which both the technical and security requirements of a web application are typically laid out. Hence web developers should have at least a basic understanding of web application security. Here are seven common security misconceptions to watch out for if you are a web application developer.

We Use a Web Framework, We Do Not Need to Worry About Security

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. However they don't prevent from logical 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 (DOM based cross-site scripting).

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.

No One Wants to Hack Our Website

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 non targeted attacks are very common, especially when vulnerabilities like Shellshock and heartbleed are discovered.

We Have Backups for Our Websites

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.

It Is Running in an Internal Network, No Need for Website Security

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.

It Is Secure Because It Is Only Accessible Via VPN

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.    

The Website Runs on SSL (HTTPS)

Unfortunately this is another common misconception. If you use SSL on your website, it will encrypt the data in transit between your website and a visitor's browser. Encryption prevents others from intercepting the unencrypted data, but it won't stop attackers from exploiting vulnerabilities that your website might have.

We Have a Web Application Firewall

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.

There Are No Excuses. Web Application Security Should Always Be Catered For

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.

Your Information will be kept private.