Auth Bypass in Sails (Javascript)
Auth Bypass in Sails with Javascript
When using Sails.js with JavaScript, an auth bypass can occur when route or controller logic fails to properly validate session or token-based authentication, especially when developers rely on implicit trust in client-side headers or misconfigure route policies.
Sails.js uses a Waterline ORM and controller-driven architecture where actions are mapped to routes. A common vulnerability arises when a controller action that should be restricted to authenticated users is left accessible due to incorrect config settings or missing policy enforcement.
For example, consider a route defined as:
// config/routes.js
module.exports.routes = {
'POST /api/auth/login': 'AuthController.login',
'GET /api/user/profile': 'UserController.profile',
};
If the UserController.profile action does not explicitly require authentication via a policy, any unauthenticated user can access it.
// api/controllers/UserController.js
module.exports = {
profile: function(req, res) {
return res.json(req.user); // Assumes req.user exists
}
};
This controller assumes req.user is populated, but without a proper policy like isAuth, an attacker can bypass authentication by directly calling the endpoint, potentially manipulating cookies or headers to mimic an authenticated session.
Additionally, if session management is misconfigured — such as using insecure cookies or not enforcing HTTPS — session hijacking can lead to unauthorized access. Another vector involves JWT handling: if token validation logic is placed in the frontend or omitted entirely for certain routes, attackers can forge valid tokens or reuse tokens across domains.
Because Sails abstracts much of the HTTP layer, developers may overlook low-level validation checks. For instance, failing to validate Authorization header schemes (e.g., Bearer tokens) or missing rate limiting on login endpoints can allow brute-force or credential stuffing attacks, indirectly enabling bypasses.
These issues fall under the OWASP API Top 10 category Broken Object Level Authorization and are frequently exploited in real-world breaches involving API-driven applications.
Javascript-Specific Remediation in Sails
To prevent auth bypasses in Sails.js, developers must explicitly enforce authentication policies and validate session data on the server side. Use Sails policies to gate access to sensitive routes.
Create an isAuth policy:
// policies/isAuth.js
module.exports = async function (req, res) {
if (!req.session || !req.session.userId) {
return res.status(401).json({ error: 'Unauthorized' });
}
return true;
};
Then apply it to the controller:
// api/controllers/UserController.js
module.exports = {
profile: function(req, res) {
return res.json(req.session.user);
},
config: {
middleware: ['isAuth']
}
};
Alternatively, use Sails hooks or config methods to enforce authentication globally for protected routes.
For JWT-based authentication, validate tokens within the controller or via a dedicated policy:
// policies/isJwtAuth.js
const jwt = require('jsonwebtoken');
module.exports = async function (req, res) {
const authHeader = req.headers.authorization || '';
const token = authHeader.replace('Bearer ', '');
try {
const payload = jwt.verify(token, process.env.JWT_SECRET);
req.user = payload;
return true;
} catch (err) {
return res.status(401).json({ error: 'Invalid token' });
}
};
Apply this policy to sensitive routes:
// config/routes.js
module.exports.routes = {
'GET /api/user/profile': 'UserController.profile',
'POST /api/user/logout': 'UserController.logout',
};
// api/controllers/UserController.js
module.exports = {
profile: { actions: [], controllerPath: 'UserController', enabled: true, methods: ['GET'], config: { middleware: ['isJwtAuth'] } },
logout: { actions: [], controllerPath: 'UserController', enabled: true, methods: ['POST'], config: { middleware: ['isJwtAuth'] } }
};
Ensure session cookies are configured securely:
// config/session.js
module.exports.session = {
secret: process.env.SESSION_SECRET,
cookie: {
path: '/',
httpOnly: true,
secure: true, // Only over HTTPS
maxAge: 86400000 // 1 day
}
};
These practices ensure that authentication is enforced server-side, reducing the risk of bypass through client manipulation or misconfigured routing.
Related CWEs: authentication
| CWE ID | Name | Severity |
|---|---|---|
| CWE-287 | Improper Authentication | CRITICAL |
| CWE-306 | Missing Authentication for Critical Function | CRITICAL |
| CWE-307 | Brute Force | HIGH |
| CWE-308 | Single-Factor Authentication | MEDIUM |
| CWE-309 | Use of Password System for Primary Authentication | MEDIUM |
| CWE-347 | Improper Verification of Cryptographic Signature | HIGH |
| CWE-384 | Session Fixation | HIGH |
| CWE-521 | Weak Password Requirements | MEDIUM |
| CWE-613 | Insufficient Session Expiration | MEDIUM |
| CWE-640 | Weak Password Recovery | HIGH |