RFC: Disable x-powered-by header by default in Express v6

[tejgokani]

Summary

Express currently enables the X-Powered-By: Express header by default on all responses. This should be disabled by default in Express v6 (while allowing opt-in for applications that want it).

Current Behavior

// lib/application.js:94
this.enable('x-powered-by');

// lib/application.js:160-162
if (this.enabled('x-powered-by')) {
  res.setHeader('X-Powered-By', 'Express');
}

Every Express application broadcasts X-Powered-By: Express by default.

Why This Matters

Security Concerns

1. Information Disclosure — Attackers use this header for reconnaissance, knowing your server is Express narrows the attack surface to Express-specific vulnerabilities
2. Security Scanner Flags — OWASP ZAP, Burp Suite, Nikto all flag this as an information disclosure issue
3. Industry Best Practice — Every security middleware (Helmet, etc.) disables this as its first action
4. Express's Own Guidance — The Express security best practices documentation recommends disabling it

Current Workaround

Every security-conscious developer must manually disable it:

app.disable('x-powered-by');
// or
app.use(helmet()); // Which disables it

Proposed Change (v6)

Disable by default:

// lib/application.js:94
this.disable('x-powered-by');

Allow opt-in:

app.enable('x-powered-by'); // For apps that want it

Breaking Change Impact

• Impact: Minimal — Very few applications depend on the presence of this header (it's anti-pattern)
• Migration: Apps that want the header can add app.enable('x-powered-by')
• Timing: Perfect for v6, which already makes breaking changes

Real-World Example

// Before (current)
GET / HTTP/1.1
X-Powered-By: Express  // ❌ Leaks framework info

// After (proposed)
GET / HTTP/1.1
// No X-Powered-By header  // ✅ Better security posture

// Apps that want it can opt-in
app.enable('x-powered-by');
GET / HTTP/1.1
X-Powered-By: Express  // ✅ Explicit choice

Questions for the Team

1. Does this align with Express v6 security improvements?
2. Should this be combined with other v6 security hardening PRs (like json escape, allowPrototypes)?
3. Timeline for v6 planning?

References

• Helmet.js disables this: https://helmetjs.github.io/
• OWASP recommendations on HTTP headers
• Express security best practices

---

Thoughts? Should we include this in v6 security hardening discussions?

[krzysdz]

Previous discussions on this topic for reference:

• How do we feel about X-Powered-By? discussions#39
• Security improvement: don't reveal powered-by #2813 (comment)