What Security Protections Does SXO Provide Out of the Box?

SXO ships with built-in security mechanisms—including default HTTP headers, path traversal protection, and safe static file handling—that are automatically applied to every response without requiring manual configuration.

The SXO framework (gc-victor/sxo) implements a secure-by-default architecture designed to protect applications against common web vulnerabilities from the moment they start. These protections are woven into the server layer and static-file handlers, ensuring that every route—whether server-side rendered, statically generated, or a 404 page—benefits from baseline security hardening.

Default HTTP Security Headers

Every response generated by SXO’s production server is automatically wrapped with a minimal but solid set of security headers. These headers are defined in src/js/server/shared/security-headers.js and merged into responses via the withSecurityHeaders utility function.

The default headers include:

• X-Content-Type-Options: nosniff – Prevents MIME-sniffing attacks that could cause browsers to execute malicious scripts disguised as images or other content types.
• X-Frame-Options: DENY – Blocks click-jacking attempts by preventing the page from being embedded in frames or iframes on other domains.
• Referrer-Policy: strict-origin-when-cross-origin – Limits referrer information sent to external sites, reducing data leakage when users navigate away from your application.

These headers are applied universally across SSR responses, generated HTML, error pages (404/500), and static assets.

Path Validation and Safe File Serving

SXO implements a rigorous validation pipeline for static file requests to prevent directory traversal and malformed URL attacks. The protections are implemented in src/js/server/shared/path.js and enforced by the static handler in src/js/server/shared/static-handler.js.

Traversal Detection and Normalization

Before serving any file, SXO performs the following checks:

• Maximum path length validation and null-byte/control-character detection to reject maliciously crafted strings.
• URI decoding with graceful failure on malformed percent-encodings.
• Segment-by-segment traversal detection that identifies .. or . segments and immediately returns a 403 Forbidden response.
• Path normalization via normalizePath and safe resolution via resolveSafePath to guarantee the resolved absolute path remains within the configured static root directory.

These mechanisms effectively neutralize directory-traversal attacks such as ../../../etc/passwd while handling edge cases like URL-encoded traversal attempts.

Cache Control and ETag Handling

For static assets, SXO automatically sets appropriate Cache-Control headers based on filename patterns. Files containing content hashes (immutable assets) receive long-term caching directives, while regular assets get short-term caching headers.

The framework also implements conditional GET support via weak ETags, which reduces unnecessary data transfer and minimizes attack surface from stale or cached malicious content. This logic resides in src/js/server/shared/static-handler.js.

Extending Security with Custom Headers

While SXO provides a secure baseline, it deliberately does not enable HTTP Strict Transport Security (HSTS) or Content Security Policy (CSP) by default. These headers require HTTPS-only environments or application-specific tuning that cannot be safely assumed for all deployments.

Developers can extend the default security headers through the securityHeaders configuration object in sxo.config.js:

// sxo.config.js
export default {
  securityHeaders: {
    "Strict-Transport-Security": "max-age=31536000; includeSubDomains",
    "Content-Security-Policy": "default-src 'self'; script-src 'self'"
  }
};

The withSecurityHeaders utility merges these custom values with the defaults in src/js/server/prod/core-handler.js, ensuring every response includes both the baseline protections and your custom policies.

Summary

• Default security headers (X-Content-Type-Options, X-Frame-Options, Referrer-Policy) are automatically applied to all responses via src/js/server/shared/security-headers.js.
• Path traversal protection validates, normalizes, and sanitizes all static file requests using utilities in src/js/server/shared/path.js and src/js/server/shared/static-handler.js.
• Safe static file serving includes cache-control logic and ETag handling to prevent stale content attacks and optimize delivery.
• Extensible security model allows developers to add HSTS and CSP through configuration while maintaining the secure-by-default baseline.

Frequently Asked Questions

Does SXO prevent click-jacking attacks by default?

Yes. SXO sets the X-Frame-Options: DENY header on every response, which prevents browsers from rendering your pages inside frames or iframes. This neutralizes click-jacking attempts without requiring any configuration.

Can SXO protect against directory traversal attacks on static files?

Yes. The static file handler in src/js/server/shared/static-handler.js uses path normalization and validation utilities from src/js/server/shared/path.js to detect and block traversal sequences like ../. Any attempt to access files outside the configured static root returns a 403 Forbidden response.

Why doesn't SXO enable CSP or HSTS by default?

SXO deliberately omits Content-Security-Policy and Strict-Transport-Security headers from the default configuration because these require application-specific policies or HTTPS-only environments that cannot be safely assumed for all deployments. Developers can add these headers through the securityHeaders configuration option in sxo.config.js.

How can I verify that SXO's security headers are working?

You can inspect the response headers using browser developer tools or command-line tools like curl. Look for X-Content-Type-Options, X-Frame-Options, and Referrer-Policy on any response from your SXO application. These headers are injected by the withSecurityHeaders function in src/js/server/shared/security-headers.js.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}