Authentication & Access Control Audits

Overview

Broken access control is the first entry in the OWASP Top 10:2025, A01 Broken Access Control, A07 Authentication Failures is on the same list, and mistakes in how an application verifies who a user is, and what that user is allowed to do, are a direct path to unauthorized access and data breaches. Our Authentication & Access Control Audit is a fixed-price, open-book review of exactly those controls in your application. We read the code, confirm what we find with targeted testing, and deliver a proof test for every confirmed finding so your team can verify the fix.

Fixed price: $5,200 for one application; $10,400 for a complex application or two related applications. Larger scopes are quoted.

Request an Audit See Pricing

What This Audit Covers

This audit goes deep on one slice of a custom application: the code paths that decide who a user is and what that user can do. That means password storage and reset, authentication bypass, session handling, access control between users and roles, and how the application integrates with single sign-on and multi-factor authentication. To review a whole application against a published standard, see our application vulnerability assessment.

We review your application against the authentication, session management, and access control requirements of the OWASP Application Security Verification Standard (ASVS), with password verifier and session requirements checked against NIST SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management. Within that scope, we focus on two areas in particular:

• Password reset. Token strength, expiry, and single use; reset links built from an untrusted Host header; responses that reveal which accounts exist; sessions that survive a password reset; and reset flows that sidestep multi-factor authentication. The OWASP Forgot Password Cheat Sheet covers the expected behavior.
• Authentication bypass. Routes and controllers that skip the authentication or authorization check, records looked up by ID without scoping them to the current user or tenant, roles that can be changed through mass assignment, token validation mistakes, and, in older Java applications, URL patterns in security constraints that don’t match what the application actually routes.

We also review:

• Access control between users and roles. Whether one user can read or change another user’s records, and whether a user can reach functions meant for a more privileged role, including in multi-tenant applications. See the OWASP Authorization Cheat Sheet.
• Single sign-on and multi-factor integration. How the application validates SAML assertions or OpenID Connect tokens from your identity provider, and whether multi-factor authentication can be skipped through another login path. See the OWASP SAML Security Cheat Sheet and the OWASP Multifactor Authentication Cheat Sheet.
• Session handling. Fixation, rotation at login, and invalidation at logout and timeout. See the OWASP Session Management Cheat Sheet.
• Password storage. If your application verifies its own passwords, the hashing algorithm matters; see What is the difference between bcrypt and SHA256?

How We Work

One of our mottos is “Code Review before Pen Test.” Authorization logic lives in the code, so we read the authentication and authorization code directly, then run targeted tests against a non-production environment, using test accounts for each user role, to confirm what the review found.

Languages and Frameworks

We review backend and frontend application code in whatever your application is built on. Authentication, authorization, input handling, and data access follow the same principles in every language, and the standards we assess against are language-neutral, so we bring the same rigor to a stack we haven't reviewed before. Our first Django audit and our first audit of a Java application on Tomcat were both in stacks that were new to us.

Applications we review include:

• Backend: Ruby on Rails, Python (Django, Flask, FastAPI), Java (Spring, and applications on Apache Tomcat, including legacy code), and JavaScript or TypeScript on Node.js
• Frontend: React, Angular, Vue, and other JavaScript or TypeScript applications
• APIs: REST and GraphQL
• Mobile: iOS and Android apps, assessed against OWASP MASVS

If your application is built on something else, ask us. We review that too.

AI-Assisted Review

With your authorization, we use AI assistance to conduct in-depth code reviews, which saves time and money. You decide where your code is processed: with our contracted U.S.-based AI providers, on offline models, or exclusively within your organization's own AI infrastructure. We can also review without AI assistance, which may increase the timeline and cost of the engagement.

We use AI assistance to audit code, not data. Before any AI is used, we analyze your repositories for secrets and other sensitive data, in the latest code and throughout the commit history, since a credential deleted from the code can still sit in an earlier commit. TruffleHog is one tool we use for this, and we use a variety of other tooling as each engagement requires.

We work within the frameworks this page describes, and when the code is available, we write unit tests that demonstrate each suspected shortcoming or exploit. At no time do we take the output of an AI model and present it as a finding. Our team reviews every finding thoroughly before it reaches your report.

What You Receive

• A findings report, with the severity of each finding and a suggested fix.
• Proof tests for confirmed findings. Each test fails against the defect and passes once it is fixed. For an application that runs in Docker, these can be container-based regression tests that run against the application over HTTP; otherwise, where practical, they are written for your own framework’s test suite, such as RSpec or Minitest, JUnit 5, or pytest.
• Test coverage recommendations for the gaps we found but did not write tests for.
• One retest within 60 days of the findings report, by re-running the proof tests against your fixes.

Fixing identified defects is not included in this audit. It can be scoped as a separate engagement, or handled through our application maintenance and remediation program.

What We Need From You

• Read access to the application’s source code repository.
• A non-production environment with test accounts for each user role.
• A technical contact who can answer questions about the application during the audit.

Independent Attestation

Frank Rietta, a life member of OWASP, can provide a signed attestation letter for your customers, auditors, or procurement office, scoped to exactly what was tested and dated as of the retest. It is an optional add-on to the audit, billed hourly and estimated with you on the onboarding call; see authentication audit pricing and add-ons.

Who This Is For

• Software development companies answering enterprise customers’ security questionnaires and contract requirements.
• HIPAA covered entities, where the HIPAA Security Rule’s access control and person or entity authentication standards apply (45 CFR § 164.312(a)(1) and (d)).
• Government agencies with custom web applications.

Where We Work

Rietta is headquartered in Alpharetta, Georgia, in Metro Atlanta, and our home region is the Southeast, including Georgia, Florida, Alabama, Tennessee, South Carolina, and North Carolina. We take on engagements nationwide, and most are handled remotely.

Pricing

• Single Application Audit

  $5,200

  $4,950 when paid by card, due on receipt

  One application and its codebase.

  Findings report with severity and suggested fixes, proof tests for confirmed findings, test coverage recommendations, and one retest within 60 days.

• Complex Application Audit

  $10,400

  $9,875 when paid by card, due on receipt

  A multi-tenant application, a large role model, or two related applications.

  Everything in the Single Application Audit, scoped to the larger application.

• Larger scope, custom quote

  Custom quote

  Several applications, or a platform beyond the Complex tier.

  We scope and price it with you on the onboarding call.

Requesting an audit asks for an onboarding call and is not an order or a binding agreement. No fee is invoiced until after that call, once we have confirmed your application, scope, and tier together, and nothing is owed unless your organization signs the Master Services Agreement and Statement of Work that follow.

Request an Audit

Learn More

• What is the difference between bcrypt and SHA256?
• Bad Password Practices are Responsible For Most Data Breaches. You Can do Better.
• What is an Abuser Story (Software)
• The Five Pillars of Information Security (And Why We Audit Accessibility)
• Archiving Federal NIST Password Compliance via OWASP ASVS Review