Rethinking web application security best practices

Application security checklists are no longer enough

The 2021 OWASP Top 10 stirred up controversy in the security community by deliberately steering away from listing specific security vulnerabilities. Instead, OWASP moved towards a more strategic approach, even adding insecure design as a category of application security weaknesses. This really brought home the message that with the speed and scale of application development, it’s no longer realistic to treat web application security as a separate process that can be reduced to ticking SQL injection and other common vulnerabilities off the list.

Any sizable organization now develops at least some of its software in-house, so sticking with AppSec understood as manually checking for the most common application vulnerabilities every now and again is costly, inefficient, and ultimately ineffective. It’s also dangerous, as vulnerabilities can linger in production for months, exposing the organization to attacks until the next testing and remediation pass.

The #1 web application security best practice is now to reliably build applications that have no known vulnerabilities as they go into production – and that means making secure coding, application security testing, and issue remediation an integral part of the development process.

The best-practice foundations of effective DevSecOps

While it’s become a bit of an industry buzzword, DevSecOps perfectly encapsulates the idea of infusing security into development and operations rather than treating it as a separate phase. Just as DevOps broke down the traditional barriers and handoffs between development and operations, so DevSecOps should (ideally) make application security an integral part of DevOps. The trick is making it happen for real-life environments, development teams, and release schedules.

Based on what we’ve seen to work for Invicti customers in their web environments, we’ve identified four strategic pillars for building a best-practice web application security strategy for the real world. Read on to learn what they are and, if you want to dive deeper, watch our on-demand webinar and read the white paper.

Find everything and test everything

In a perfect world, developers would always deliver secure code, and all web assets across an organization would be carefully cataloged and managed. In reality, nothing is ever waterproof, and all the information you get about your web environments will always carry some uncertainty. Even a single security defect can be enough for malicious hackers to get through, so the only way to be sure you’re doing all you can is to constantly monitor your web environments, test everything, and trust nothing.

While it is definitely a best practice to keep a central inventory of all your websites, applications, and APIs for easy commissioning, maintenance, and decommissioning, most organizations still have only a vague idea of their true web attack surface. A large organization can have hundreds or even thousands of web assets, including websites, web applications, web services, and web APIs. Modern service-oriented applications will often connect to dozens of services and expose their own functionality via interfaces, exponentially increasing the attack surface. This makes automated and continuous web asset discovery a vital part of any web security program.

As for the testing itself, you can choose from a variety of approaches and tools, each with its own benefits and tradeoffs. Again, the ultimate goal is to ensure that you have no known security issues in production, and the way to get there will be different for each organization. To get consistent vulnerability scanning coverage across multiple applications, technologies, architectures, and development phases, you will need at least good quality dynamic application security testing (DAST) with workflow automation to keep up with your development pipeline.

Test and remediate at the speed of development

Today’s development teams are under pressure to innovate and deliver on time, typically working in short, agile sprints, with no time to wait for security. To be effective, application security testing and remediation must be built into the software development lifecycle (SDLC) and work effectively without breaking the pace of development. And because the entire dev pipeline is heavily automated, the security testing and remediation process needs to be integrated into it with the same level of automation.

While it’s easy to focus on the testing part, efficient and lasting remediation is the real key to building more secure web apps and improving code quality in the long run. To take a specific example, cross-site scripting (XSS) vulnerabilities are by far the most common web application security weakness, and if you’re reporting them to developers without effective remediation guidance, they will keep resurfacing and multiplying endlessly due to partial fixes that only work in a specific context (or don’t work at all). The way to reduce XSS issues in the long run is to help developers understand and address the root cause, which is missing or incomplete user input validation.

Automating the vulnerability testing and remediation process requires tools that interface directly with existing development and testing toolchains. Developers rely on issue trackers to plan and execute tasks, so getting actionable security issues into the tracker is vital to get them seen and resolved. Most importantly, whatever security tools you use, they need to report actual security risks without flooding developers with non-actionable or downright false results.

Work with trustworthy and actionable data

Striking the right balance between finding all the vulnerabilities that matter and minimizing the amount of noise in vulnerability reports is the linchpin of any security scanning effort. This goes far beyond the usual discussions about false positives. While it’s absolutely true false positives generate extra work that can negate many or all of the efficiency gains from automation, the fundamental issue is being able to trust that the data you’re feeding into your workflows is both correct and actionable.

To get accurate results that reflect your true security posture in the current threat environment, you need to take special care when choosing your tooling. Just as securing your websites and applications is now far more than testing for specific vulnerabilities, so your decisions about security testing tools are no longer a simple matter of ticking tech boxes. Instead, you should always ask what measurable security improvements a tool will make in your unique environment and workflows. Merely piling on another source of security reports won’t always translate to better application security – and could even make it worse if your security teams and developers get overloaded with irrelevant information.

The flip side of working only with trusted data is to implicitly distrust anything that hasn’t been tested. In practice, this means not only testing every part of your existing web application environment but also testing all new builds and every single vulnerability fix. Incomplete or superficial fixes are the bane of application security, as the underlying issues will sooner or later resurface and generate more work than was saved by doing a quick and dirty fix. Best-practice AppSec should thus include tools and workflows that automatically and relentlessly test and retest everything that is moving towards production.

Keep going without fail

If you’re reading this cybersecurity blog, you likely don’t need reminding that cyberattacks are a 24/7 security threat and can lead to increasingly costly data breaches, loss of sensitive data, malware deployments, and crippling downtime. Manual penetration testing, while a vital periodic task, is nowhere near enough to continuously maintain a consistent security posture across all your web assets. So apart from security testing in the SDLC, you also need to regularly test sites and applications that are already in production. This is especially important for third-party assets and anything that is not in active development and therefore not covered by whatever security testing you are doing in the dev pipeline.

Even if your applications haven’t changed recently, dozens of new vulnerabilities and attack vectors are discovered every day. What you thought was secure last week or even yesterday might be vulnerable today, so once again: test everything, trust nothing. Safe yet accurate vulnerability scanning for production applications is a whole separate topic, but the recommended practice is to clone your current production environment and scan the clone, not the live deployment. That way, you can cover the full set of potential issues in your production code and setup, including any security misconfigurations, but without affecting the actual live environment.

To make this level of testing possible while also minimizing the time and effort required for remediation, you should build a reliable and fully automated security testing process that starts from the first lines of source code and covers every part and phase of development and operations, up to and including production. Again, this makes a quality DAST solution essential to test the entire application in staging and production. With modern DAST-based platforms such as Invicti, you can also extend testing left into development to complement your existing static application security testing (SAST) or even serve as your only application testing technology – especially useful for getting started with AppSec.

Cybersecurity hygiene essentials

Building a DevSecOps process is about making security everyone’s business, so your application security radar needs to extend beyond the application itself to also cover operational security. This includes implementing sometimes fiddly but always essential security measures both in your applications and on the web server. For example, your servers need to send the right security headers, most notably HSTS to enforce SSL/TLS encryption for all traffic and CSP (Content Security Policy) to restrict potentially malicious content sources. Similarly, your teams should know how to set secure cookie attributes to minimize the risk of session hijacking attacks.

Looking even wider, a web application firewall (WAF) is essential both as an extra line of defense and as a way to temporarily mitigate vulnerabilities until a patch or fix is ready. (Reminder: WAF rules are only band-aids and never permanent solutions to security issues.) An efficient patching process is also crucial to minimize attack vectors related to open source libraries and other third-party components in your web stack, though unlike in network security, patching is only one aspect of the remediation process.

Finally, going back to OWASP’s inclusion of insecure design as a security weakness, your software teams need to consider security in everything they do and plan. To give a specific example, enforcing proper access control is crucial to minimize the risk of unauthorized access that could lead to attackers obtaining sensitive information or escalating from a minor initial breach to full system compromise. But secure and effective access control isn’t just about strong passwords or multi-factor authentication (though both are important) – it starts with a secure design of user roles and privileges that follows both the required business logic and the principle of least privilege. And that’s not something you can graft on at the last minute.

The Invicti way of doing AppSec

Each organization is different, and there are many ways to set up an effective program for building secure web applications. More often than not, it takes a lot of time to find, deploy, and fine-tune all the tools and workflows – and during that time, you’re not getting value from them. At Invicti, we’ve come up with a DAST-first solution that integrates into any web application development workflow and maintains maximum coverage with the option of diving deeper with integrated IAST and SCA. It’s not the only way to do AppSec, but we’re firmly convinced it is the way of the future.

To learn more, watch our on-demand webinar on AppSec best practices and read our white paper: Enterprise Web Application Security Best Practices