Content Security Policies

Overview

Apiboost takes a defense-in-depth approach to frontend security, implementing browser-enforced controls that protect portal users against the most common web application threats — including cross-site scripting (XSS), clickjacking, session hijacking, and data injection.

Content Security Policy

Apiboost enforces a strict Content Security Policy (CSP) on every page response, aligned with W3C CSP Level 3 and the OWASP XSS Prevention recommendations.

Key characteristics of our CSP implementation:

• No `unsafe-inline` for style or script elements. All inline content requires a cryptographic token that is unique per request and unpredictable to attackers. This is the industry-standard approach recommended by Google, Mozilla, and OWASP.

• Policy is managed dynamically. Security teams can update allowlisted domains and directives without requiring a software deployment, enabling rapid response to supply chain changes or security incidents.

• Fallback to secure defaults. If the policy service is unreachable, the application continues operating under a hardened baseline — it never falls back to an unprotected state.

Third-Party Script Controls

All third-party scripts and stylesheets loaded by the portal are subject to explicit governance:

• Analytics and tag management scripts are validated against a known-good format before loading and are covered by policy directives that prevent them from loading content from unapproved origins.

• Icon and font assets are served as static files rather than being injected at runtime, eliminating a common bypass vector.

• Customer-specific stylesheets are loaded under the same content policy controls as first-party content.

Transport & Session Security

• All sub-resources are automatically upgraded to HTTPS (`upgrade-insecure-requests`).

• Session cookies are `httpOnly` (inaccessible to JavaScript), `sameSite=lax` (CSRF mitigation), and expire after 24 hours.

• Authentication supports both username/password and SAML 2.0 SSO.

Application Hardening

• Server version information is not disclosed in HTTP response headers.

• Production builds do not expose source maps.

• All incoming request paths are sanitised to prevent path traversal and null-byte injection.

• Internal API credentials are compared using constant-time operations to prevent timing-based attacks.

• Framing of the application by external origins is blocked to prevent clickjacking.

Compliance Alignment

Reporting a Vulnerability

If you believe you have found a security vulnerability in Apiboost, please contact us at security@apiboost.com rather than opening a public issue. We will respond within 2 business days and work with you on coordinated disclosure.