10 common developer misconceptions about web application security

Where it all begins: The troubled relationship between software innovation and security

Software development is all about making things work and creating new functionality that solves problems and unlocks new possibilities. That creative buzz is part of the appeal of web development – and yet Invicti research shows that 32% of web developers spend at least five hours a day addressing security issues. All too often, inefficient communication and inadequate tools reduce cause developers to treat security-related requests as a chore and distraction that has no clear reason and brings no visible results. This mistrust is reinforced by common misconceptions about web application security – many not exclusive to developers.

Misconception #1: Security is not a development problem

Reality: Application security is a crucial part of modern web development, especially as you move towards DevSecOps.

Let’s start with the mother of all application security misconceptions: that security is someone else’s problem. Whether you’re putting your trust in tools, external systems, or the security team, it’s tempting to put security out of mind and focus only on building software. In reality, web applications are now so complex and can be attacked in so many ways that the only way to truly secure them is to make security everyone’s business – starting but also ending with development. After all, whenever vulnerabilities are found in your custom web applications, the fix requests eventually end up in development, so efficiently dealing with them as they arrive is crucial to avoid bottlenecks and prevent professional burnout.

Misconception #2: Our web framework takes care of security

Reality: A good quality framework can prevent many security flaws but is nowhere near enough on its own.

Web frameworks and libraries have revolutionized development, providing the scaffolding to build production sites and applications using only a fraction of the time and resources that it would take to develop from scratch. Choosing a framework with a solid security record is a must as it helps you entirely avoid some classes of technical vulnerabilities – but only some classes, and only when using the framework as intended. As an example we’ve written about previously, it is pretty difficult to introduce a cross-site scripting vulnerability when using React unless you deliberately sidestep the built-in safeguards. But even when used as intended, frameworks can only prevent a small subset of vulnerabilities in typical use cases, so they are only the starting point for secure coding.

Misconception #3: We run security checks in the IDE, so we’re already secure

Reality: Static code checking only covers a small part of the full application security picture.

Web development toolsets now commonly include some sort of code security checker, sometimes even as a free plugin. These have the benefit of enforcing some level of security awareness from the very first line of code but also have their drawbacks – they can only identify a limited set of issues and are prone to false alarms that obscure valid alerts with irrelevant ones. While having a security-oriented tool amongst all the other code checkers in your IDE is always a good idea, it is only one of many small steps on the road to having applications you can call secure. And just as having a build with no syntax errors is no guarantee that it works correctly, so passing all your static security checks is no guarantee that the app is secure – because there’s so much more that can go wrong.

Misconception #4: Browsers have security covered with built-in protection against attacks

Reality: Browser security complements application security but was never intended to replace it.

In the heady days of cross-site scripting (XSS) everywhere about a decade ago, browser vendors experimented with building XSS filters into the browser itself. While these safeguards were never fully effective and have been removed from most modern browsers, they’ve left behind the misconception that it’s the job of the browser to prevent attacks on web applications. In reality, browser security is an entirely separate (and vital) area of cybersecurity, and you should never rely on the browser as an additional line of defense for your applications. Instead, web developers should do their best to follow accepted industry standards and specifications to maximize the chances of browsers processing and rendering their applications correctly – and securely.

Misconception #5: All our sites use HTTPS, so they are secure

Reality: HTTPS only protects you from snooping and tampering, not from malicious traffic.

Seeing the padlock icon and “This website is secure” message can create a false sense of security – if you have HTTPS everywhere and all your traffic is encrypted, that means everything is safe, right? Unfortunately, while enforcing HTTPS (by setting HSTS headers) is definitely a crucial best practice to prevent man-in-the-middle (MITM) attacks, it provides no protection against application-level attacks where the threat actor already has a valid connection. For example, if an attacker can access or create a valid user account in a vulnerable HTTPS-only application, they will have free rein to attempt SQL injection, privilege escalation, and other exploits – all within a securely encrypted connection.

Misconception #6: The app only runs on an internal network, so security isn’t an issue

Reality: Advanced attackers can use compromised web-facing systems to indirectly attack vulnerable applications, even in internal networks.

Moving the “someone else’s problem” thinking further afield, there’s the myth that anything that’s on an internal network and not directly accessible from the Internet is inherently safe from web-based attacks. In reality, there are vulnerabilities such as server-side request forgery (SSRF) that, if present in production applications, can allow advanced attackers to target even internal systems via another server. And that’s quite apart from the fact that, in a cloud-first world, many organizations no longer have a physically isolated internal network, only private cloud instances. But that’s a separate can of security worms.

Misconception #7: We only allow VPN access, so our applications are secure

Reality: VPNs are powerful tools for Internet privacy but not a blanket solution for securing your web assets.

The pandemic-fueled shift towards remote work has seen VPNs, or virtual private networks, go from a specialist tool to a staple of enterprise IT, serving as the remote-working counterpart of the physical office network. And while they do provide additional separation and access control, just like internal networks, VPNs shouldn’t be seen as a guarantee of security for your web applications. If attackers do manage to access the VPN (for example, using stolen credentials, compromised employee accounts, or a bit of social engineering), any vulnerable internal applications will be wide open to attack.

Misconception #8: Our web application firewall will stop any attacks

Reality: WAFs are not designed to be the only line of application defense, especially as they can be bypassed by determined attackers.

Another AppSec myth originating from the days of network perimeter defense is that a firewall is enough to keep you safe. Web application firewalls (WAFs) are the web analog of network firewalls, filtering HTTP traffic to (hopefully) detect and block attack attempts. Often also serving as load balancers, WAFs provide an extra level of security and are invaluable for temporarily blocking zero-day exploits until a fix is implemented. However, they cannot (and are not intended to) detect all possible attacks, and as long as an underlying vulnerability exists, attackers are likely to find ways to exploit it that get around WAF rules.

Misconception #9: We have backups, so we can restore if anything happens

Reality: Backups are important for data retention and business continuity but won’t reduce the collateral damage from a data breach. 

A backup strategy has always been a critical component of the overall security policy, and there is no substitute for having good backups and a reliable recovery plan. But even the best backups won’t prevent cybersecurity incidents, and knowing you still have a copy of any lost confidential data won’t be much consolation when that data is stolen and leaked. Backups can only prevent data loss and won’t help with the other potential consequences of a cyberattack, from costly downtime to loss of reputation, making them only one part of any serious application security program. Making your applications secure in the first place is just as important as always being ready for recovery.

Misconception #10: Nobody could possibly want to attack us

Reality: The majority of cyberattacks are automated and indiscriminate, so every organization can be a target.

Admittedly not limited to developers, this misconception plays into the universal human belief that bad things only ever happen to other people. From smaller companies who think they don’t make an attractive target to enterprises that fail to fully appreciate the vastness of their attack surface, organizations hope against all odds (and evidence) that application security doesn’t really concern them because they won’t be hit.

The uncomfortable truth is that real cybercriminals are not lone hunters roaming the web in search of prey but organized criminal organizations that fill the global web with automated attack probes 24 hours a day. In fact, malicious bots account for 39% of all Internet traffic – more than all human users combined. And as soon as the bots find a known weakness (think Log4Shell), you’re on the list. All you can do is make sure your applications are as secure as you can get them.

Fact: Systematic AppSec means less risk and less work for everyone

Modern web application security is complex, multi-layered, and constantly changing, just like the web applications themselves. Reducing it to occasional firefighting leads to delayed and inefficient fixes, with vulnerabilities that keep resurfacing and piling more issues on the ever-increasing backlog. From that point of view, ignoring application security during development for any of the reasons listed above is not only dangerous but can generate more work than it saves. Building effective security testing and remediation directly into the software development lifecycle (SDLC) simply makes more sense on all levels.

After all, would you rather spend your time building innovative applications or wildly chasing security defects? Thought so.