Fix Insecure API Management in Sails

Sails.js is notorious for its 'Blueprints' feature which, while convenient for prototyping, creates a massive attack surface by exposing automatic CRUD routes. Insecure API management in Sails typically stems from leaving these blueprints enabled in production, coupled with a permissive 'allow-all' policy configuration. Attackers leverage shadow routes to bypass intended business logic and exfiltrate data directly from the models.

The Vulnerable Pattern

// config/blueprints.js
module.exports.blueprints = {
  actions: true,
  rest: true,
  shortcuts: true // CRITICAL: Allows DB mutation via GET params
};
// config/policies.js
module.exports.policies = {
’*’: true // GLOBAL ALLOW: No authentication required for any endpoint
};

The Secure Implementation

To harden the API, we first disable all blueprint shadow routes. This forces the application to use explicitly defined routes in `config/routes.js`, preventing attackers from guessing model-backed endpoints. Next, we implement a 'Default Deny' strategy in `policies.js`. By setting the wildcard to `false`, any newly created controller is secure by default until a specific policy (like JWT verification or Role-Based Access Control) is applied. Finally, we move logic out of generic blueprints and into controlled actions where input validation and rate limiting can be enforced.

// config/blueprints.js
module.exports.blueprints = {
  actions: false,
  rest: false,
  shortcuts: false
};
// config/policies.js
module.exports.policies = {
’*’: false, // DEFAULT DENY: Everything is locked by default
‘UserController’: {
‘find’: ‘isAuthorized’,
‘update’: ‘isOwner’,
‘delete’: ‘isAdmin’
}
};
// api/policies/isAuthorized.js
module.exports = async function (req, res, proceed) {
const token = req.headers.authorization?.split(‘Bearer ’)[1];
if (!token) return res.forbidden();
try {
const decoded = await jwksClient.verify(token);
req.user = decoded;
return proceed();
} catch (e) {
return res.forbidden();
}
};