I've been a huge fan of OWASP for a very long time, having spoken at their conferences, contributed to their projects, consumed many of their resources and met some really awesome people along the way! Just recently, one of the very popular OWASP projects, the Application Security Verification Standard (ASVS), had a major update released and it brought with it some exciting changes.
OWASP ASVS
I'd bet that most people are familiar with the OWASP Top 10 project, one of the most notable flagship projects to come out of OWASP!
The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.
For me, coming in at a close second place is the OWASP ASVS project, another project aimed at helping the community with a structured approach to taking care of application security.
The OWASP Application Security Verification Standard (ASVS) Project provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development.
One of the things I love about the ASVS is the straightforward, "no nonsense" approach. They aren't requirements imagined in a vacuum, beyond the realistic hope or requirement of anyone trying to implement, instead they seek to be effective and balanced. This quote from the early paragraphs of the document in the 'Level evaluation' section, where you consider which level of compliance is appropriate for you, says a lot:
Levels are defined by priority‑based evaluation of each requirement based on experience implement‑ ing and testing security requirements. The main focus is on comparing risk reduction with the effort to implement the requirement. Another key factor is to keep a low barrier to entry.
I've provided a copy of the standard below and if you're not familiar with ASVS, I'd really recommend checking it out, even if only for you to use it as a reference rather than a hard requirement.
The parts where we can help
As a platform focused on providing organisations with the tools they need to be secure, there is of course a huge overlap between the requirements in the OWASP ASVS 5.0.0 standard, and Report URI's wide range of products and features. Some of these requirements are more generalised and are something we can help with on a more holistic approach, and some of them are slam-dunk cases where Report URI can 100% help you meet that requirement. We'll go through these requirements at a high level and look at how Report URI can help, and we'll also provide additional guidance and context to help you understand the requirements better. Let's start with the big hitters first, and go from there, and also remember to check the compliance level which we will provide for each requirement to see if it's something you will need to consider. Here's a quick summary of the compliance levels if you aren't familiar with them.
✅ Level 1 — Informational / Low Assurance
Low-risk apps (e.g. simple brochure sites or MVPs).
✅✅ Level 2 — Standard Assurance (Baseline Compliance)
Apps handling personal data, business logic, or moderate sensitivity.
✅✅✅ Level 3 — High Assurance
Financial systems, healthcare apps, and other high-value or high-impact systems.
You can assess which level of the requirements is suitable for your application, and then you can use that to guide you through the following sections to determine which apply to you and your application.
V3.1 Web Frontend Security Documentation
This is a pretty sensible requirement to protect against the impact of malicious content find its way in to your site, and as a Level 1 requirement, is applicable to all sites.
3.2.1 (Level 1)
Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API, a user‑uploaded file or other resource is requested directly). Possible controls could include: not serving the content unless HTTP request header fields (such as Sec‑Fetch‑*) indicate it is the correct context, using the sandbox directive of the Content‑Security‑Policy header field or using the attachment disposition type in the Content‑Disposition header field.
Whenever you're using Content Security Policy, it's always advisable to monitor that policy and ensure there isn't anything happening that you weren't expecting. The sandbox directive is particularly powerful in the suggested context and allows you to isolate the downloaded content.
V3.4 Browser Security Mechanism Headers
Honestly at this point in the realm of security online, who doesn't love Security Headers?! There is so much powerful protection you can leverage by configuring these relatively simple mechanisms, it's no wonder that they got an entire section in the standard. You should read this entire section, absolutely, but here are the parts we can help with specifically.
3.4.3 (Level 2 and Level 3)
Verify that HTTP responses include a Content‑Security‑Policy response header field which defines directives to ensure the browser only loads and executes trusted content or resources, in order to limit execution of malicious JavaScript. As a minimum, a global policy must be used which includes the directives object‑src ‘none’ and base‑uri ‘none’ and defines either an allowlist or uses nonces or hashes. For an L3 application, a per‑response policy with nonces or hashes must be defined.
3.4.6 (Level 2)
Verify that the web application uses the frame‑ancestors directive of the Content‑Security‑Policy header field for every HTTP response to ensure that it cannot be embedded by default and that embedding of specific resources is allowed only when necessary. Note that the X‑Frame‑Options header field, although supported by browsers, is obsolete and may not be relied upon.
3.4.7 (Level 3)
Verify that the Content‑Security‑Policy header field specifies a location to report violations.
That last one is particularly noteworthy, and I'd say that any application with a CSP in place should be monitoring for those violations because you want to know if things have been configured incorrectly, or worse, an attack is currently ongoing! All of that guidance is sensible though and these are all standard things that we'd be recommending to our customers anyway.
V3.6 External Resource Integrity
Another common risk being addressed by this requirement is that of your JavaScript supply chain. Over the years we have seen so many attacks where a website is compromised not because they were breached, but because one of their dependencies was breached instead! Whilst this requirement focuses specifically on the venerable Subresource Integrity (SRI), at the time of writing we have a new feature in beta that will go far beyond the capabilities of SRI and provide even more value. Reach out if you're interested in joining the beta!
3.6.1 (Level 3)
Verify that client‑side assets, such as JavaScript libraries, CSS, or web fonts, are only hosted externally (e.g., on a Content Delivery Network) if the resource is static and versioned and Subresource Integrity (SRI) is used to validate the integrity of the asset. If this is not possible, there should be a documented security decision to justify this for each resource.
Getting Started
If you want to start the process of improving the security of your web application, you can get started with a free trial on our website right now, or reach out to our team if you'd like some support through this process. Maybe you're looking to avoid the risk of a costly data breach in the future, maybe you have some particular compliance requirement you're trying to meet, or perhaps you've identified a specific concern you'd like to address. Either way, we're here to help, and we have more than a decade of experience to draw from as we support you.
To achieve this, the ASVS standard is a great basis to work from, and I want to quote the following objectives from the standard itself:
• Use as a metric - Provide application developers and application owners with a yardstick with which to assess the degree of trust that can be placed in their Web applications,
• Use as guidance - Provide guidance to security control developers as to what to build into security controls in order to satisfy application security requirements, and
• Use during procurement - Provide a basis for specifying application security verification requirements in contracts.
No matter which angle you're coming from, I'm hoping to see increased adoption of the OWASP ASVS requirements over time and the benefits that will bring to security across the Web.