# What Security Protections Does SXO Provide Out of the Box?

> Discover SXO's built-in security protections like default HTTP headers, path traversal protection, and safe static file handling for automatic, hassle-free security.

- Repository: [Víctor García/sxo](https://github.com/gc-victor/sxo)
- Tags: security
- Published: 2026-03-02

---

**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`](https://github.com/gc-victor/sxo/blob/main/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`](https://github.com/gc-victor/sxo/blob/main/src/js/server/shared/path.js) and enforced by the static handler in [`src/js/server/shared/static-handler.js`](https://github.com/gc-victor/sxo/blob/main/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`](https://github.com/gc-victor/sxo/blob/main/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`](https://github.com/gc-victor/sxo/blob/main/sxo.config.js):

```javascript
// 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`](https://github.com/gc-victor/sxo/blob/main/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`](https://github.com/gc-victor/sxo/blob/main/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`](https://github.com/gc-victor/sxo/blob/main/src/js/server/shared/path.js) and [`src/js/server/shared/static-handler.js`](https://github.com/gc-victor/sxo/blob/main/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`](https://github.com/gc-victor/sxo/blob/main/src/js/server/shared/static-handler.js) uses path normalization and validation utilities from [`src/js/server/shared/path.js`](https://github.com/gc-victor/sxo/blob/main/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`](https://github.com/gc-victor/sxo/blob/main/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`](https://github.com/gc-victor/sxo/blob/main/src/js/server/shared/security-headers.js).