We value your privacy

We use cookies to analyze site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Audit and compliance
  3. Website security audit
Website and web application security audit for US businesses

Software supply chain failures entered the OWASP Top 10 at number three. Most organizations cannot list what their site depends on.

Current edition is the OWASP Top 10 2025, and the categories have shifted since the last one. Broken access control holds first place, security misconfiguration takes second, and software supply chain failures have arrived at third. Auditing against the current list tells you where your applications genuinely stand today, rather than where the 2021 list placed them.

Book a web application auditSee the current Top 10
Website and web application security audit for US organizations
  • Top 10 2025The current released edition
  • A01 access controlStill the first category
  • A03 supply chainDependencies, and what they pull in
  • ConfigurationSecond category, and rarely tested
What we test

Six things that determine whether a web audit turns up anything genuine.

Every serious web application audit works against the OWASP Top 10, and 2025 is the currently released edition. Test against a superseded list, or against whatever profile a scanner shipped with by default, and the findings you get back will be perfectly true while no longer being the ones that matter most.

Broken access control, still the first category

It sits at A01 in the 2025 edition, exactly where it sat before. First place belongs to it because it is simultaneously the most common failure and among the most damaging: one user reaching data or functions belonging to another user, or to an administrator. Automated tools catch some of it. The remainder needs a person who understands what the application is supposed to permit, which makes access control testing the least automatable part of any web audit.

Security misconfiguration, at number two

Second place in the 2025 list. Default credentials still in place. Errors returning far too much detail. Features enabled that nobody needed. Hardening missing from the platform underneath the application. Headers simply absent. It ranks second because it is everywhere and costs an attacker almost nothing to exploit. It is also the category an audit scoped purely to application code misses most often, because the finding lives in the deployment rather than in the source.

Software supply chain failures, now at number three

Third in the 2025 edition. A modern web application is assembled out of dependencies, and every one of those dependencies drags its own dependencies along. The audit question runs deeper than whether a known vulnerable package is present. It asks whether anybody in the business can produce that list at all, and whether the build process would notice if something inside it changed overnight.

Cryptographic failures and injection

They sit at A04 and A05 respectively. Cryptographic failures cover data that ought to have been protected in transit or at rest and was not, or was protected poorly enough to amount to the same thing. Injection is still on the current list, which after two decades of sustained attention says something uncomfortable about how applications continue to be built under time pressure.

Design, authentication, and integrity

Insecure design at A06, authentication failures at A07, and software or data integrity failures at A08. The first of those three lies entirely beyond what a scanner can reach, because it concerns decisions taken before anybody wrote a line of code. Finding it means reading how the application is supposed to work rather than probing how it responds.

Logging, alerting, and exceptional conditions

Security logging and alerting failures at A09, mishandling of exceptional conditions at A10. Both concern what the application does at the moment something goes wrong: whether anybody would find out, and whether the failure itself opens a door. They sit at the bottom of the list, and they are reliably the two categories nobody has ever examined.

What changed, and why it matters

The list has moved on. An audit written against the 2021 categories is measuring the decade before this one.

OWASP publishes the current edition while keeping the older ones accessible. That is helpful as reference material and distinctly unhelpful when a report quietly measures you against the wrong one.

  • OWASP Top 10 2025 is the most recent released version. Both the 2021 and 2017 editions stay published as reference material, which is precisely how a report can look entirely current while working from a superseded list.
  • Software supply chain failures have moved to A03 in the 2025 edition. Most web audits historically treated that category as a footnote at best. Its promotion reflects how applications genuinely get built now, which is assembled out of dependencies rather than written from scratch.
  • The current edition places mishandling of exceptional conditions at A10 and security logging and alerting failures at A09. Both are concerned with what happens once something goes wrong, and that is reliably the part of any application least likely to have been tested by anybody.
  • The practical implication is straightforward enough. Ask any proposed audit which edition it works against. Where the answer comes back as 2021, the findings will be genuine while the coverage reflects a different set of priorities from the ones OWASP now publishes.
Ask us to audit against the current list
How we approach it

Four things separating a genuine web audit from a scan report with a cover page.

Automated tools are genuinely useful and they cover one specific part of the current list very well indeed. Unfortunately the categories they cannot reach are the ones producing actual incidents, which is why the method matters considerably more than the tooling.

Access control gets tested using real accounts at every privilege level

Broken access control still heads the list, and finding it means acting as one user and deliberately attempting to reach another user data and functions. That needs test accounts at every privilege level plus somebody who understands what the application is supposed to permit in the first place. It is the least automatable part of the work and reliably the most productive.

The dependency list is treated as a finding in its own right

Software supply chain failures occupy A03 in the current edition. The opening question is not whether some vulnerable package is present. It is whether anybody in the business can produce the list at all. Where the answer is no, that absence is the finding, because a dependency inventory nobody maintains is a vulnerability nobody will notice arriving.

We start by finding the applications you forgot

Scope something from memory and you will miss the campaign microsite an agency built, the staging environment that still resolves, and the API somebody exposed for a single integration. Running external attack surface discovery before scoping consistently adds applications to the list, and the forgotten ones are reliably in worse shape than any of the ones you remembered.

Retesting happens, because no finding is closed until somebody verified it

Any report ending at delivery leaves the single most important question unanswered: did the fix actually work. Retesting is built into the engagement rather than offered as an option, and it regularly reveals that a change addressed the one example given in the report rather than the underlying issue across the whole application.

Where this matters most

Six situations common in American businesses where a web audit is the correct first move.

Something external usually triggers it. A customer requirement, a question from a regulator, a demand from a payment provider, or an incident that happened to somebody else. Occasionally it is a launch, and a launch is genuinely the best time to do this.

A business accepting payments or personal data through its website

Cryptographic failures at A04 and broken access control at A01 are the two categories that expose customer data most directly, and both are precisely what CCPA, CPRA and the other state privacy laws assume you already have under control. Where card data enters the picture, having an application security position is part of what PCI DSS expects rather than a pleasant addition to it.

An organization whose customers now ask about application security

Enterprise procurement now routinely asks web application security questions, and a SOC 2 audit will ask how changes get tested before they ship. A documented audit against the current OWASP Top 10 with findings that were retested is a considerably stronger answer than a scan report. It also answers the next customer questionnaire at a fraction of the cost, because the work already exists.

A group whose applications were built by several agencies across many years

Different builders, different frameworks, wildly different levels of care, and nobody anywhere holding a complete picture. Security misconfiguration at A02 and software supply chain failures at A03 dominate in this profile, because every application carries the assumptions of whoever built it along with whichever dependencies that person happened to pick.

A regulated firm with a customer-facing portal

Authentication failures at A07 and security logging and alerting failures at A09 carry the most weight here, because an examiner working under GLBA or NYDFS Part 500 asks two questions: is access properly controlled, and would you know if somebody abused it. That second question is the one businesses are consistently least prepared for.

An organization about to launch something

Insecure design at A06 is cheapest to find before anything ships, because the finding concerns a decision rather than a defect, and revisiting a decision after launch costs real money. Auditing during development, rather than treating it as a gate immediately before go-live, is the only point at which that category is genuinely addressable.

An institution with more public sites than anybody realized

Departments, campaigns, events and student bodies produce web properties without pause, very often on infrastructure the central team has never laid eyes on. Discovery before scoping is not optional in this environment, and the forgotten sites are consistently where security misconfiguration and unpatched dependencies are at their worst.

Three positions

How US organizations check their web applications.

The middle column is common and produces a reassuring report. An automated scan does find genuine issues, and it is structurally incapable of finding the first, third or sixth categories on the current list.
Injection and common flaws found
Audited against the current Top 10Yes
Automated scanning onlyYes
Never testedNo
Access control tested across roles
Audited against the current Top 10Yes
Automated scanning onlyRarely
Never testedNo
Insecure design identified
Audited against the current Top 10Yes
Automated scanning onlyNo
Never testedNo
Dependency and supply chain reviewed
Audited against the current Top 10Yes
Automated scanning onlyPartly
Never testedNo
Platform configuration reviewed
Audited against the current Top 10Yes
Automated scanning onlySometimes
Never testedNo
Logging and alerting assessed
Audited against the current Top 10Yes
Automated scanning onlyNo
Never testedNo
Failure paths examined
Audited against the current Top 10Yes
Automated scanning onlyNo
Never testedNo
Findings verified after fix
Audited against the current Top 10Yes
Automated scanning onlyNo
Never testedNot applicable
Against the current 2025 edition
Audited against the current Top 10Yes
Automated scanning onlyDepends on the tool
Never testedNot applicable
Report a customer would accept
Audited against the current Top 10Yes
Automated scanning onlySometimes
Never testedNo
Feature
Audited against the current Top 10
Automated scanning only
Never tested
Injection and common flaws found
YesYesNo
Access control tested across roles
YesRarelyNo
Insecure design identified
YesNoNo
Dependency and supply chain reviewed
YesPartlyNo
Platform configuration reviewed
YesSometimesNo
Logging and alerting assessed
YesNoNo
Failure paths examined
YesNoNo
Findings verified after fix
YesNoNot applicable
Against the current 2025 edition
YesDepends on the toolNot applicable
Report a customer would accept
YesSometimesNo
The current list

The OWASP Top 10 2025, and what each category means for an American web estate.

The category codes and names come from OWASP. What sits in the right hand column is what we most commonly find inside each category, which is our own observation rather than anything OWASP published.

Category

A01:2025

Name
Broken Access Control
What we most often find
Object identifiers sitting in URLs that nothing checks against the signed-in user

Category

A02:2025

Name
Security Misconfiguration
What we most often find
Error pages saying too much, default accounts left in place, and platform hardening never applied

Category

A03:2025

Name
Software Supply Chain Failures
What we most often find
No one can produce the dependency list, and nothing is watching it for changes

Category

A04:2025

Name
Cryptographic Failures
What we most often find
Sensitive fields stored or sent without the protection everybody assumed was already there

Category

A05:2025

Name
Injection
What we most often find
Parameterization applied nearly everywhere, and one legacy query where somebody forgot

Category

A06:2025

Name
Insecure Design
What we most often find
A workflow placing trust in a client-supplied value it should never have trusted

Category

A07:2025

Name
Authentication Failures
What we most often find
The password reset flow, how sessions are handled, and rate limiting on the login path

Category

A08:2025

Name
Software or Data Integrity Failures
What we most often find
A deployment pipeline that would not detect an unauthorized change

Category

A09:2025

Name
Security Logging and Alerting Failures
What we most often find
Application events logged nowhere anybody monitors

Category

A10:2025

Name
Mishandling of Exceptional Conditions
What we most often find
Failure paths giving away internal detail, or leaving the application somewhere unexpected
CategoryNameWhat we most often find
A01:2025Broken Access ControlObject identifiers sitting in URLs that nothing checks against the signed-in user
A02:2025Security MisconfigurationError pages saying too much, default accounts left in place, and platform hardening never applied
A03:2025Software Supply Chain FailuresNo one can produce the dependency list, and nothing is watching it for changes
A04:2025Cryptographic FailuresSensitive fields stored or sent without the protection everybody assumed was already there
A05:2025InjectionParameterization applied nearly everywhere, and one legacy query where somebody forgot
A06:2025Insecure DesignA workflow placing trust in a client-supplied value it should never have trusted
A07:2025Authentication FailuresThe password reset flow, how sessions are handled, and rate limiting on the login path
A08:2025Software or Data Integrity FailuresA deployment pipeline that would not detect an unauthorized change
A09:2025Security Logging and Alerting FailuresApplication events logged nowhere anybody monitors
A10:2025Mishandling of Exceptional ConditionsFailure paths giving away internal detail, or leaving the application somewhere unexpected
How an engagement runs

Five steps, and retest is included rather than optional.

Two to five weeks in most cases, driven by how many applications are involved and how complex each is, delivered remotely, with a retest window following remediation.
  1. 1

    Discover what actually exists

    Before scoping against whatever list somebody hands us, we run external discovery to find the applications that list leaves out. Campaign sites. Staging environments that still resolve. APIs exposed for one integration years ago. The forgotten ones are reliably in worse condition than the remembered ones, which makes them exactly the wrong things to leave outside the scope.

  2. 2

    Scope against the current Top 10 and gather access

    We need test accounts at every role, because access control at A01 simply cannot be tested without them. Beyond that, the dependency manifest for A03, the deployment configuration for A02 and A08, and whatever design documentation exists for A06. What we are able to see determines what we are able to find, and the difference between generous access and grudging access is substantial.

  3. 3

    Testing covers all ten categories rather than only the automatable ones

    Automated coverage goes where automation is genuinely effective. After that comes manual work across access control, design, authentication flows, the integrity of the deployment pipeline, logging, and the failure paths. Since the categories a tool cannot reach are the ones producing real incidents, they receive proportionally more of the available time.

  4. 4

    Report against the categories, with reproduction and impact

    Every finding is mapped to its OWASP category and comes with steps to reproduce it, a description of the actual impact rather than a generic severity rating, and a specific remediation. A finding nobody can reproduce never gets fixed, and a severity carrying no business impact never gets prioritized.

  5. 5

    Retest and confirm the fix reached the pipeline

    We verify each finding is genuinely closed, and that regularly reveals somebody fixed the specific example while leaving the underlying pattern untouched. We also confirm the fix exists in the source and in the pipeline rather than only in the running instance, since otherwise the very next deployment quietly reintroduces it.

Straight answers

What organizations ask about web application audits.

The OWASP Top 10 2025, published as the most current released version. Both the 2021 and 2017 editions remain available for reference purposes, which is worth knowing precisely because a report can appear current while working from a superseded list. Ask any provider which edition they work against, and expect a specific answer rather than a vague one.

In order: broken access control, security misconfiguration, software supply chain failures, cryptographic failures, injection, insecure design, authentication failures, software or data integrity failures, security logging and alerting failures, and mishandling of exceptional conditions.

It covers part of the list well and structurally cannot reach the rest. Broken access control at A01 requires acting as one user and attempting to reach another's data. Insecure design at A06 concerns decisions made before code was written. Software supply chain failures at A03 require the dependency picture. Those three are among the most consequential categories and none of them is a scanning problem.

Because it reflects how applications are now built. A modern web application is assembled from dependencies, each of which has its own dependencies, and the resulting tree is frequently larger than the code anybody in the organization wrote. Software supply chain failures at A03 in the 2025 edition acknowledges that the assembled parts are as much the application as the code around them.

Yes, and it matters. Security misconfiguration sits at A02, and a large share of what falls into that category lives in the deployment rather than the source: default accounts, verbose errors, unnecessary features enabled, absent hardening, missing headers. An audit scoped only to application code systematically misses the second-ranked category.

They should be in scope, and they frequently have weaker access control than the web interface in front of them, because the interface is what people test. The same categories apply, and A01 broken access control in particular tends to be more exposed at the API layer where object identifiers are handled directly.

For access control testing to mean anything, yes, and at every role that exists. The central question at A01 is whether one user can reach data or functions belonging to another user or to an administrator, and answering it requires the ability to act as each of them in turn. An audit run without authenticated access covers your public surface and leaves the single most productive category completely untested.

Either works, with different constraints attached. A representative test environment permits more thorough testing with no risk to live data or to availability. Testing production is entirely possible and gets conducted far more carefully, inside agreed windows and against a defined stop condition. What matters above both is that whatever we test genuinely resembles the environment serving your customers.

We do, and we treat it as part of the engagement rather than something sold separately. Verification regularly shows that the specific example named in the report got fixed while the underlying pattern survives elsewhere in the application. It also confirms the fix reached the source and the deployment pipeline rather than living only in the running instance.

The two overlap while answering different questions. An application audit works systematically through the OWASP categories to establish where the application stands. A penetration test tries to achieve an objective by whatever route happens to exist, which might be the application, the network, your people, or some combination of all three. Most businesses need the audit first and the test after it.

That describes most of our clients, and it shapes the remediation conversation rather than the audit itself. Findings go to whoever is able to fix them. The genuinely useful additional output is a clear statement of which findings sit in the application, which sit in the deployment, and which sit in the dependency set, because those three frequently belong to different owners and take different remediation routes.

Applications change without pause, which means a point-in-time audit describes exactly that, a point in time. Annually is a sensible baseline for a stable application, more frequently where development is active, and always following a significant change to authentication, to authorization, or to the deployment pipeline. Dependency monitoring should run continuously rather than periodically. Each engagement is scoped per business, driven by how many applications are involved, whether authenticated areas and APIs fall in scope, and how much the discovery step adds to the list before anybody commits to anything.
Scoping the audit

Fifteen questions that determine whether the audit is useful.

Group one establishes what is actually being tested. Group two covers what access we are given. Group three deals with what happens to the findings afterwards, and that is the point at which most web audits stop being worth anything.

Scope

  • Which applications are in scope?
    Including the ones marketing built.
  • Do you know all your public sites?
    External discovery usually finds more.
  • Does the scope include the platform, or only the code?
    A02 lives in the deployment.
  • Are the APIs in scope?
    They frequently have weaker access control.
  • Is there an authenticated area?
    A01 findings are almost all behind login.

Access

  • Will we get test accounts at each role?
    Access control testing needs several.
  • Is there a test environment?
    Or are we testing production carefully.
  • Can we see the dependency manifest?
    A03 is far faster with it.
  • Can we see the deployment configuration?
    A02 and A08 depend on it.
  • Is there any design documentation?
    A06 cannot be found without context.

Afterwards

  • Who fixes the findings?
    Internal team, or the agency who built it.
  • Is there a retest included?
    A finding is not closed until it is verified.
  • Does the fix reach the pipeline?
    Or only the running instance.
  • Will dependencies be watched from now on?
    A03 is a continuous problem.
  • When is the next audit?
    Applications change continuously.
Related reading

The pages around this one.

Penetration testing

Testing driven by an objective across the entire estate, rather than working systematically through one application.

Learn more

Defender EASM

Locating the applications and sites that never appeared on any list in the first place.

Learn more

Vulnerability assessment

The wider scanning program that runs between audits.

Learn more
Next step

Ask whoever built your site to send over the dependency list, and time how long it takes to arrive.

Software supply chain failures hold third place in the current OWASP Top 10. Where nobody can produce that list quickly, you already have a finding, and it happens to be the one predicting how much else an audit is likely to surface.

Book a web application auditSee the audit practice

Related Services

Explore more solutions that work great with this service

Penetration Testing

Penetration testing for US businesses across external, internal, web

Learn more

Vulnerability Assessment

Vulnerability assessment for US businesses across external attack

Learn more

Cloud Security Posture Audit

Cloud security posture audits for US organizations: true inventory

Learn more

Cyber Incident Response

Cyber incident response for US businesses. 24/7 on-call IR engineers

Learn more

SOC 2 Readiness

Get audit-ready for the report your buyers ask for

Learn more
GR IT SERVICES

IT services for US businesses,
delivering enterprise-grade solutions
remotely, coast to coast.

Microsoft CSP PartnerApple Jamf PartnerCISGuard

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support USA
  • IT AMC USA
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • hello@gritservices.io
  • gritservices.io

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie PolicyCCPA/CPRA