Type of Authentication Vulnerabilities

authentication vulnerabilities

Malicious attacks on applications continue to take new forms as such actors keep up with and attempt to surpass new security protocols. This has led to new system and authentication vulnerabilities that, if not corrected, could be at potential risk of attack. 

Types of Authentication Vulnerabilities

Let’s discuss some of the main authentication vulnerabilities that can pose a serious risk to your applications.

Broken authentication

Broken authentication ties in directly with user access. In this case, malicious attacks are programmed to compromise that information which is used to validate credentials, such as passwords. These stolen keys are then used to gain easy, unauthorized access to secure systems. 

One example of broken authentication is the Session ID URL, which ends up containing the session ID in the website URL. The result is that anyone who may be casually sharing the site with their friends may accidentally share their ID along with it. Visitors from that shared URL will then be using that ID to access the content.


The URL above contains the session ID needed to access secure content.

Another way a broken authentication may occur is by credential stuffing. Databases of compromised user IDs are used to gain access to secured networks. They are based on the assumption that most users reuse the same IDs and passwords across multiple sites, with a significant success rate. Sophisticated bots that attempt multiple logins at once make it a dangerous attack. 

The process works by setting up a bot that can work across multiple websites at once. An automated process will match login information with the website, identifying successful logins. Related account data, such as credit cards or other vulnerable information, are then stored to supplement phishing attacks.


One solution to this issue is to use a helper function to check password strength and protect it before storing it in the database:


public void Register(@RequestBody UserInfo user){




            password = saltPassword(password);

        database.saveUser(User.email, user.password);


    catch(Exception ex){

        throw ex;







Another possible solution is to add an authentication check to ensure there is no data breach:


public class AdminController {

    @RequestMapping(value = "/admin/user/data", method = RequestMethod.GET)


    public List<String> getUserDetails(Authentication authentication) {

        if (authentication instanceof AdminAuthenticationToken){

            return userDao.getDetailsFromDb();





Broken Access Control  

Access control defines the limitations of user access and interaction with data. The vulnerability occurs when users are able to interact with elements of the data that they should not be able to. This can include actions they should not be able to perform, or information they should not be seeing. 

An example of this includes users being able to edit, rather than just view, scores awarded on a digital scoresheet. Attackers can make use of such vulnerabilities to obtain confidential information and unauthorized access to systems. 

Insecure IDs can often cause broken access control when they are not configured properly. Even randomized user IDs are not sufficient to properly protect against this vulnerability. For example, the authenticated user ID:


Should allow only the user to access confidential information attached to their account. With broken access control, one could type in:


One would be able to change the user ID following the same pattern of IDs assigned to valid users, and access their private information without requiring authorization.


This vulnerability can be corrected by adding a custom claim to the token payload, which can be used to verify user ID. The username attached with the ID could then be checked to verify access claim:


.claim("username", username) 

.claim("role", role) 

.setIssuedAt(Date.from(Instant.ofEpochSecond(1629736517L))) .setExpiration(Date.from(Instant.ofEpochSecond(1661272517L))) 


( SignatureAlgorithm.HS256, 

"Simple Secret" 



Cross-Origin Resource Sharing (CORS) Policy

Web-based applications’ URL connect user browsers to the server. In this regard, the Same Origin Policy ensures that the URL can only be accessed with the same protocol, domain name, and path schema. While typically considered a secure protocol, it becomes more restrictive with web-based applications that link to and require access to third-party applications. 

A CORS policy is instead used that allows this interaction to occur. It gives the browser permission to access shared resources with allowed HTTP headers that are considered safe. However, creating a specified safe list is an arduous task, and may in fact, limit access to some connected third-party apps due to oversight. The solution then becomes to create a CORS policy that lets the browser connect to both servers it shares. 

The vulnerability in this scenario occurs when a CORS policy is used but is not well-defined. This leaves holes in the policy, which attackers can use to gain access to these servers. 

A CORS implementation request includes an Access-Control-Allow-Origin header to define authorized origins:

HTTP/1.1 200 OK

Access-Control-Allow-Origins: https://sample.example.external

Access-Control-Allow-Credentials: true

Server: X-Sample-Server 

Content-type: text/html; charset=UTF-8 

Connection: close

Date: Fri, 26 August 2022 07:31:17 GMT

Content-length: 171




   Sample EXP Web Application


<link rel=”icon” href=”favicon.ico” />








CORS misconfiguration includes Access-Control-Allow-Origin (ACAO) which allows two-way communication between third parties. It can be used to modify or steal sensitive data, such as usernames and passwords. 

The second misconfiguration is Access-Control-Allow-Credentials (ACAC) which allows third-party sites to execute actions that are privileged and which they should not be able to perform. This could include changing sensitive and private information such as passwords.


A multitude of solutions are presented to a CORS misconfiguration vulnerability. One is to send requests to a proxy at the backend. It adds a CORS header to the request, acting as an intermediary between client and server. Given a frontend request such as this:


In its place, the request can be sent to:


The proxy receives the request, passing it on to the server, and then adds “Access-Control-Allow-Origin: *” to the response. 

Another possible solution is to build your own proxy. It eliminates the need to depend on or share the proxy with clients, and as many servers can be dedicated to it as one likes. The proxy can be built in Node.js as:

const express = require('express');

const request = require('request');

const app = express();

app.use((req, res, next) => {

res.header('Access-Control-Allow-Origin', '*');



app.get('/sample/example', (req, res) => {


   { url:

    'https://sample-api-strict-cors.appspot.com/sample/example' },

(error, response, body) => {

  if (error || response.statusCode !== 200)


   return res.status(500).json({ type: 

   'error', message: err.message });






const PORT = process.env.PORT || 3000;

app.listen(PORT, () => console.log(`listening on ${PORT}`));


Authentication vulnerabilities can expose your systems and networks to security risks. Attackers can take advantage of such risk to surpass your protocols and cause user damage. Main examples of authentication vulnerabilities include broken authentication, broken access control. We’ve provided solutions on that above, as well as a detailed discussion of the CORS policy. If you need any more help on application security, we have a number of articles that offer guidance on the subject.

Leave a Comment

Your email address will not be published. Required fields are marked *

Related Posts

Regex is a useful string of characters that defines a search pattern. In the security world, regular
When developing an application or any other software, the security of the finalized product is one of
Sometimes the development teams employ unconventional practices to fix bugs or add new features without realizing the
Scroll to Top