How to detect broken authentication with

Updated at
Reading time

OWASP Top 10 is an industry staple for a reason: because it’s incredibly well documented and provides a reliable framework for security specialists striving to prioritize vulns.

No matter what your specialty is – pentesting, bug bounty hunting, etc. – you can count on this list. Ready to put the pedal to the metal when it comes to detecting vulnerabilities in the OWASP Top 10? Here’s a little help.

After our guide on how to detect injection flaws with, it’s time to dive into a discussion about Broken Authentication. Go through the motions with professional pentesters Daniel Bechenea and Cristian Cornea.

What are Broken Authentication vulnerabilities?

While it’s one of the easiest issues to verify during a penetration test, it can be wrecking if left unresolved. Broken Authentication has the potential to cause a massive personal information (PII) leak for all employees or clients (or both!) – all without the attacker exploiting a technically complex vulnerability. All it takes is default credentials or a sensitive page where authentication is not enforced.

Broken Authentication is a web application security flaw that emerges when authentication and session management functions are incorrectly implemented. This allows attackers to compromise and harvest sensitive data and take over valid accounts or even the entire application. The technical impact of this vulnerability is very severe as the attacker will have access to all the resources a valid user can reach.

The root cause for Broken Authentication attacks

The root cause of this web application risk lies in session management and password security issues. The most frequent sources of Broken Authentication vulnerabilities in web applications are the complexity of validating and managing the session in a proper way and not enforcing a password policy.

Also, as you may have experienced during your assessments, many developers leave default credentials enabled for several reasons such as inertia, lack of proper documentation, or simply forgetting to remove them. No matter the reason, it still exposes their organization to a substantial risk.

How is a broken authentication different from the other OWASP issues?

The most challenging thing about this vulnerability is the practice used in web app development. Using weak credentials is so common that developers don’t even realize they’re making the web app vulnerable by design.

Password and session management issues go unchecked and security reviews are not always the norm. Most often, there’s no malicious intent behind this widespread practice but cybercriminals don’t care how it happens as long as they can fully take advantage of it.

Why are Broken Authentication issues so pervasive?

If there’s no security standard, developers must follow while developing, maintaining, or implementing an application, most devs will default to the easiest way of ensuring the app works. This often makes security an afterthought and the result is a goldmine for attackers.

Unfortunately for organizations – but luckily for malicious actors – the bulk of web applications today are vulnerable to this security flaw.

The 6 common types of Broken Authentication attacks

Creativity is not something cybercriminals lack, so let’s go over the main reasons attackers exploit Broken Authentication vulnerabilities.

Credential stuffing

Credential stuffing is like a brute force attack where you already have access to a breached or compromised database. The tactic involves trying various combinations of breached username and password combinations against the web application to gain access to the accounts.

This technique often works when users set the same password across different applications.

Missing or bypassing authentication

This happens when the application is missing important validation checks during the authentication process.

Here’s an example: not comparing the password the user (or attacker) puts in with the one in the app’s database. When this happens, anyone can log in with just the provided username.

Default credentials

I wonder why people who still have the “admin/admin” combination enabled ask themselves why they got breached. Don’t you think about this too?

Default credentials are not a technical issue in itself but rather a negligent approach from system administrators who don’t take their time to change them. Later down the road, this turns into a full application/system compromise. Ouch.

Password spraying

Password spraying is a technique in which you attempt to access a large number of user accounts with a bunch of frequently used passwords.

This is different from traditional brute force attacks where you try to gain access to a single account – it’s all about high-scale compromise here.

Hijacking an authenticated session

This is an attack technique where you take control of the target user’s session after obtaining, guessing, reverse-engineering, or generating its session ID, resulting in a full identity impersonation.

Authenticated session fixation

This is somewhat the opposite of session hijacking.

Session fixation is a web application attack in which you can log in with the session ID of a user who has logged off from the application, but whose action didn’t get invalidated.

While there are lots of ways to manipulate this vulnerability, your job is to find and report it. So when you get to this item on your checklist, check out this time-effective tactic to scan for default and weak credentials using

How to identify Broken Authentication Issues with

Log into your account.

Under Tools, check out the Web Application Testing menu and select Website Scanner.

select the Website Scanner In the scanner’s configuration, set your target URL. Select the “Full Scan” option. Do not add any authentication method, because your goal is to find resources you can access without being authorized. If you want to use your time effectively, choose to get an email notification when the scan is finished.

scan your URL target with the Website Scanner Once the scanner wraps up, you can go through the results and check the “Interesting Files Found” to see which files/folders you can access in the application without being authenticated.

scan results with the Website Scanner

How to identify Default and Weak Credentials with

Besides spotting Broken Authentication issues tied to your targets, you can also uncover default, vulnerable username/password combos from the same platform.

Here’s how to do it:

Log into your account.

Under Tools, check the Infrastructure Testing menu for the Password Auditor tool.

Password Auditor scanner In the Password Auditor – Find Weak Credentials configuration, set your target URL. Select the “Use port from target URL” option. For Services, choose only “HTTP”. Ensure that “Common usernames (default) is set for Usernames and “Common Passwords (default)” is set for Passwords. Also, you can choose to get an email notification when the scan is finished. So easy and so fast!

scan URL target with the Password Auditor tool

How to report Broken Authentication vulnerabilities using

Putting together a report for an issue as frequent as Broken Authentication should be a matter of minutes. Because you have a lot of work on your hands, we’re providing a way to make your workflow smoother and more effective.

Let’s quickly break it down.

Once logged into your account, use the Reporting feature to select and include the findings you want to pass on to the customer or your peers.

You can use one of our predefined reporting templates for the most common Broken Authentication vulnerabilities. They’re pre-filled with essential details about your findings (vulnerability description, risk level, recommendation, CVE score) so you can save hours of manual work.

These ready-to-use findings templates related to Broken Authentication include:

  • Default credentials in use reporting template

default credentials reporting template

  • Session fixation reporting template

session fixation reporting template

  • Session does not expire reporting template

session does not expire reporting template

If you’re specific about your reporting, you can also: add your own findings, create your own template, and edit it with specific information before exporting the report.

How to Add Findings Manually to Your Penetration Testing Results generated by 🛡️

How to create re-usable templates that include Broken Authentication vulnerabilities

Connect to your account.

Under the Reporting menu, select Finding templates.

On the Finding templates page, you can add a new Broken Authentication template.

broken authentication template On the Add template page, you can edit the Vulnerability description, Risk description, Risk level, Vulnerability recommendation, Vulnerability CVSS score, Vulnerability CVE based on your needs. It’s easy to modify and customize any of these sections to include links, code snippets, screenshots, tables, and other helpful elements.

finding template with vulnerability details Once you set up your templates, you’ll be able to use them with almost every pentest engagement you’ll run going forward.

How to prevent Broken Authentication vulnerabilities

There are various steps you can do to prevent this category of OWASP Top 10 vulns.

First and foremost, make sure to enforce a strong password security policy and session management policy in your application. This way, every time a user sets a password for their account in it, the app will force the user to set a strong and uncommon password.

password policy editor Also, restrict the session to a specific duration and only allow a limited number of simultaneous sessions. Other than that, following these guidelines can also be hugely helpful:

  • Implement brute force protection in the web application such as rate-limiting, or accounts lockout

  • Enforce a strong and uncommon password policy

  • Educate users about phishing, social engineering, and credentials harvesting attacks

  • Limit the number of simultaneous logins for the same user

  • Invalidate session cookies after a password change, account disable, and logout.

How can system administrators fix this vulnerability?

System administrators can prevent the exploitation of this vulnerability in two ways:

  • by cross-checking the multiple logins of the same user from different locations and

  • by verifying brute force attempts against the users on the web application.

Key takeaways

  • Review and apply session validation for all the sensitive endpoints.

  • Scan for weak and default credentials using to provide devs and sysadmins with a list of priorities to tackle

  • Ensure your password policy is correctly enforced by all the systems and for all the users.

NoteDaniel Bechenea, penetration tester at, also contributed to this step-by-step guide. 

Get vulnerability research & write-ups

In your inbox. (No fluff. Actionable stuff only.)

Ready to apply what you read?

Use our free tools

Related articles