HIGH auth bypasssailsbearer tokens

Auth Bypass in Sails with Bearer Tokens

Auth Bypass in Sails with Bearer Tokens — how this specific combination creates or exposes the vulnerability

In Sails.js, an Auth Bypass involving Bearer Tokens typically arises when token validation is inconsistently applied across controller actions or when middleware does not enforce token presence for protected routes. Sails does not enforce authentication by default; it relies on developer-defined policies. If a policy that checks for a Bearer Token is omitted or misconfigured, an attacker can call endpoints without credentials, effectively bypassing intended access controls.

Bearer Tokens are often passed in the Authorization header as Authorization: Bearer <token>. Vulnerabilities occur when:

  • Token verification is only implemented in some controllers or actions, leaving administrative or data endpoints unguarded.
  • Token parsing logic does not properly reject malformed or missing headers, allowing requests to proceed without a valid token.
  • CORS settings or route shortcuts allow preflight or unauthenticated access to routes that should require a token.

For example, an API might have a policy that checks for a Bearer Token on most routes but forgets to apply it to a user profile endpoint. An authenticated user could then modify the route to access another user’s profile by changing the resource identifier, combining BOLA/IDOR with Auth Bypass. Because the token was never validated for that endpoint, the request succeeds despite insufficient authorization.

In black-box scanning, middleBrick tests whether endpoints enforce Bearer Token validation by sending requests with and without valid tokens. It checks for inconsistent policy application, missing header checks, and whether token presence is required for sensitive operations. Findings highlight endpoints that return successful responses without valid authentication, indicating a potential Auth Bypass in the Sails application.

Bearer Tokens-Specific Remediation in Sails — concrete code fixes

To secure Bearer Tokens in Sails, enforce token validation consistently using policies and ensure proper parsing and rejection of invalid tokens. Below are concrete remediation steps with code examples.

1. Create a token verification policy

Generate a policy using the Sails CLI: sails generate policy verifyToken . Implement strict Bearer Token extraction and validation in api/policies/verifyToken.js:

module.exports.verifyToken = function verifyToken(req, res, next) {
  const authHeader = req.headers.authorization;
  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return res.unauthorized('Missing or invalid Authorization header.');
  }
  const token = authHeader.split(' ')[1];
  if (!token) {
    return res.unauthorized('Bearer token missing.');
  }
  try {
    // Replace with your actual token validation logic, e.g., jwt.verify
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    req.user = decoded;
    return next();
  } catch (err) {
    return res.unauthorized('Invalid token.');
  }
};

2. Apply the policy globally or selectively

In config/policies.js, apply the policy to protect all endpoints by default, then explicitly allow public routes:

module.exports.policies = {
  '*': 'verifyToken',
  'AuthController': {
    'login': true,
    'register': true
  },
  'UserController': {
    'viewProfile': true // Only if you intentionally allow unverified access
  }
};

For Sails routes defined in config/routes.js, ensure that sensitive routes do not bypass the policy:

'POST /user/profile': {
  controller: 'UserController',
  action: 'updateProfile',
  skipAllPolicies: false // Ensure policies run
},

3. Validate token format and reject malformed requests

Ensure your policy rejects requests with malformed Authorization headers. For example, reject headers that contain Bearer but no token, or use an incorrect scheme:

const authHeader = req.headers.authorization || '';
const parts = authHeader.split(' ');
if (parts.length !== 2 || parts[0].toLowerCase() !== 'bearer') {
  return res.badRequest('Authorization header must be formatted as: Bearer <token>');
}

4. Combine with ownership checks to prevent BOLA

After token verification, enforce ownership or role-based access on sensitive resources. For a user profile endpoint in UserController.js:

updateProfile: async function (req, res) {
  const userId = req.param('id');
  if (req.user.id !== userId && !req.user.isAdmin) {
    return res.forbidden('You do not have permission to access this resource.');
  }
  // Proceed with update logic
  return res.ok();
}

5. Test with curl examples

Verify your fixes using curl commands:

# Valid request
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." http://localhost:1337/user/profile

# Missing token
curl http://localhost:1337/user/profile

# Malformed token
curl -H "Authorization: Token abc123" http://localhost:1337/user/profile

These steps ensure that Bearer Tokens are properly validated for all sensitive endpoints in Sails, reducing the risk of Auth Bypass and combining effectively with checks for BOLA/IDOR and other access control issues.

Related CWEs: authentication

CWE IDNameSeverity
CWE-287Improper Authentication CRITICAL
CWE-306Missing Authentication for Critical Function CRITICAL
CWE-307Brute Force HIGH
CWE-308Single-Factor Authentication MEDIUM
CWE-309Use of Password System for Primary Authentication MEDIUM
CWE-347Improper Verification of Cryptographic Signature HIGH
CWE-384Session Fixation HIGH
CWE-521Weak Password Requirements MEDIUM
CWE-613Insufficient Session Expiration MEDIUM
CWE-640Weak Password Recovery HIGH

Frequently Asked Questions

How does middleBrick detect Auth Bypass vulnerabilities in Sails APIs using Bearer Tokens?
middleBrick tests endpoints both with and without valid Bearer Tokens in the Authorization header, checks for inconsistent policy application, and verifies that token validation is enforced on all sensitive routes. Missing or misconfigured token checks are flagged as potential Auth Bypass findings.
Can middleBrick test Bearer Token validation if the API uses custom authentication schemes?
middleBrick primarily tests standard Bearer Token patterns (Authorization: Bearer <token>). Custom schemes may require additional configuration or manual validation, as the scanner relies on recognized header formats for initial checks.