Configuring HTTP Security Headers for Enhanced Browser Protection in JSON Configuration File

Overview

Beginning with version 10.5, the application supports an optional addHeaders section in the root of the JSON configuration file (default.json). This feature allows administrators to define additional HTTP response headers that the application will automatically include when serving web content.

These headers are commonly used to strengthen browser‑level security, reduce exposure to common attack vectors, and enforce organizational compliance requirements. This article explains what each header does and why you may want to enable or customize them in your environment.

Sample Configuration

json

CODE

"addHeaders": {
  "X-Frame-Options": "SAMEORIGIN",
  "X-XSS-Protection": "1; mode=block",
  "X-Content-Type-Options": "nosniff",
  "Referrer-Policy": "no-referrer-when-downgrade",
  "Content-Security-Policy": "default-src 'self'; connect-src 'self' accounts.google.com; style-src 'self' 'unsafe-inline' fonts.googleapis.com unpkg.com maxcdn.bootstrapcdn.com; img-src 'self' www.square-9.com data:; font-src 'self' data: fonts.gstatic.com; script-src 'self' 'unsafe-inline' 'unsafe-eval' cdn.ckeditor.com unpkg.com maxcdn.bootstrapcdn.com; frame-ancestors 'self'; form-action 'self'; base-uri 'self';",
  "Strict-Transport-Security": "max-age=31536000; includeSubDomains"
}

Why These Headers Matter

Each header plays a specific role in protecting users and content. While none of these replace server‑side security controls, they provide an important additional layer of defense at the browser level.

Below is a breakdown of each header and the value it provides.

X‑Frame‑Options

Purpose: Prevents your application from being embedded inside an <iframe> on another site.

Why it matters: This mitigates clickjacking attacks, where a malicious site overlays invisible UI elements to trick users into clicking unintended actions.

Common values:

SAMEORIGIN – Only pages from the same domain may embed the app.
DENY – No framing allowed at all.

X‑XSS‑Protection

Purpose: Enables the browser’s built‑in cross‑site scripting (XSS) filter.

Why it matters: Although modern browsers rely more on Content Security Policy (CSP), this header still provides a fallback layer for older environments.

Common value: 1; mode=block – Block the page if XSS is detected.

X‑Content‑Type‑Options

Purpose: Prevents MIME‑type sniffing.

Why it matters: Browsers sometimes guess file types, which can lead to scripts being executed unexpectedly. Setting this header ensures the browser respects the declared content type.

Common value: nosniff

Referrer‑Policy

Purpose: Controls how much referrer information the browser sends when navigating away from your site.

Why it matters: Referrer URLs can contain sensitive information. This header helps you control what is exposed to external sites.

Common value: no-referrer-when-downgrade – Send referrer only over HTTPS, never to HTTP.

Content‑Security‑Policy (CSP)

Purpose: Defines which sources of scripts, styles, images, fonts, and frames the browser is allowed to load.

Why it matters: CSP is one of the strongest defenses against XSS and data injection attacks. It restricts the browser to only load resources from trusted origins.

Example capabilities:

default-src 'self' – Only load content from the same origin.
script-src / style-src – Whitelist approved CDNs.
frame-ancestors – Controls which sites may embed your app.
form-action – Restricts where forms can submit data.

A well‑designed CSP significantly reduces the attack surface of any web application.

Strict‑Transport‑Security (HSTS)

Purpose: Forces browsers to always use HTTPS when communicating with your site.

Why it matters: HSTS prevents protocol downgrade attacks and ensures encrypted communication even if a user types http:// manually.

Common value: max-age=31536000; includeSubDomains – Enforce HTTPS for one year across all subdomains.

When Should You Configure These Headers?

You should consider enabling or customizing these headers if:

Your organization has security compliance requirements (HIPAA, SOC 2, ISO 27001, etc.)
You want to reduce exposure to browser‑based attacks
You are hosting the application in a publicly accessible environment
You need to restrict embedding, tighten CSP rules, or enforce HTTPS
You want to align with modern security best practices recommended by OWASP

These headers are optional, but strongly recommended for production deployments.

How the Application Uses These Headers

When the addHeaders section is present:

The application injects each header into every HTTP response it serves.
Headers are applied consistently across all routes.
Administrators can add, remove, or modify headers without code changes.
Invalid or unsupported headers are ignored by browsers without breaking functionality.

This gives you fine‑grained control over browser behavior while keeping configuration simple and centralized.

Summary

The addHeaders configuration block allows administrators to enforce modern browser security controls directly from the application’s JSON configuration file. These headers help protect against clickjacking, XSS, MIME‑type confusion, insecure referrer leakage, mixed‑content issues, and protocol downgrade attacks.

While optional, they are highly recommended for any environment where security, compliance, or controlled browser behavior is a priority.