Securing Express Apps: express-csp-header vs helmet

When building web applications with Express.js, setting proper HTTP security headers is non-negotiable. Two common tools for this are express-csp-header and helmet. While both can configure Content Security Policy (CSP), they differ significantly in scope, maintenance, and philosophy. Let’s break down how they work in practice.

🛡️ Scope: Focused Tool vs Full Security Suite

express-csp-header does one thing: generate and set the Content-Security-Policy header. It provides a clean API to define CSP directives using JavaScript objects instead of raw strings.

// express-csp-header: Only sets CSP
import express from 'express';
import csp from 'express-csp-header';

const app = express();

app.use(csp({
  policies: {
    'default-src': [csp.SELF],
    'script-src': [csp.SELF, 'https://trusted.cdn.com'],
    'style-src': [csp.SELF, 'https://fonts.googleapis.com']
  }
}));

helmet sets multiple security headers out of the box, including CSP, but also:

• X-Content-Type-Options
• X-Frame-Options
• X-XSS-Protection
• Strict-Transport-Security
• Referrer-Policy
• And more

You can enable all defaults or pick specific ones:

// helmet: Sets many headers, including CSP
import express from 'express';
import helmet from 'helmet';

const app = express();

// Enable all recommended headers
app.use(helmet());

// Or just CSP with custom config
app.use(helmet.contentSecurityPolicy({
  directives: {
    'default-src': ["'self'"],
    'script-src': ["'self'", 'https://trusted.cdn.com'],
    'style-src': ["'self'", 'https://fonts.googleapis.com']
  }
}));

🔧 Configuration Style: Object-Based vs String-Based Directives

Both libraries let you define CSP using JavaScript objects, but their syntax differs slightly.

express-csp-header uses constants like csp.SELF to represent 'self':

// express-csp-header
app.use(csp({
  policies: {
    'img-src': [csp.SELF, 'data:', 'https://images.example.com']
  }
}));
// Produces: img-src 'self' data: https://images.example.com

helmet expects you to write values as strings, including quotes for special keywords:

// helmet
app.use(helmet.contentSecurityPolicy({
  directives: {
    'img-src': ["'self'", 'data:', 'https://images.example.com']
  }
}));
// Produces: img-src 'self' data: https://images.example.com

Note: In helmet, you must include the single quotes around 'self' as a string literal. This is closer to the actual HTTP header format but can be error-prone.

🔄 Maintenance and Ecosystem Fit

As of recent checks, helmet is actively maintained, widely adopted, and aligns with current OWASP security recommendations. It’s updated regularly to reflect evolving best practices (e.g., deprecating X-XSS-Protection in favor of modern CSP).

express-csp-header, while functional, shows signs of reduced maintenance. Its GitHub repository has not seen significant updates in years, and it doesn’t handle newer CSP features as gracefully. For new projects, this raises sustainability concerns.

🎯 When to Use Which?

Use helmet if:

• You’re building a production application and want defense-in-depth.
• You’d rather not manually configure each security header.
• You value community support and up-to-date defaults.

Example: A SaaS dashboard serving sensitive user data.

// Recommended setup for most apps
app.use(helmet({
  contentSecurityPolicy: {
    directives: {
      'default-src': ["'self'"],
      'script-src': ["'self'", "'unsafe-inline'"], // adjust as needed
      'connect-src': ["'self'", 'https://api.yourservice.com']
    }
  }
}));

Consider express-csp-header only if:

• You’re working in a constrained environment where you only need CSP.
• You already manage other headers via reverse proxy (e.g., Nginx) or CDN.
• You’ve verified compatibility with your Express version and accept the maintenance risk.

Example: A microservice that only serves JSON and relies on an edge gateway for other headers.

// Minimal CSP-only setup
app.use(csp({
  policies: {
    'default-src': [csp.NONE],
    'frame-ancestors': [csp.NONE]
  }
}));

⚠️ Critical Note on CSP Reporting

Both libraries support CSP violation reporting, but implementation differs.

helmet includes report-uri and report-to in its CSP directive options:

app.use(helmet.contentSecurityPolicy({
  directives: {
    'default-src': ["'self'"],
    'report-uri': ['/csp-violation-report-endpoint']
  }
}));

express-csp-header requires you to add the report-uri as a string in the policy array:

app.use(csp({
  policies: {
    'default-src': [csp.SELF],
    'report-uri': ['/csp-violation-report-endpoint']
  }
}));

However, note that report-uri is deprecated in favor of report-to, which requires additional header configuration. helmet makes this easier by allowing full control over all directives.

✅ Final Recommendation

For nearly all Express.js applications, helmet is the better choice. It’s secure by default, actively maintained, and reduces the chance of missing critical headers. Use express-csp-header only in niche cases where you have full control over your infrastructure and deliberately isolate CSP management — and even then, audit its compatibility carefully.

Remember: Security isn’t just about CSP. Headers like X-Content-Type-Options and Strict-Transport-Security prevent entire classes of attacks. helmet gives you those for free.