Default Security Headers

[aminulacter]

No default security headers
Should implement common security headers by default

[hopeseekr]

“Common security headers” usually refers to the standard HTTP headers that modern browsers and intermediaries honor to harden applications against click-jacking, MIME-type sniffing, XSS, mixed-content, referrer leakage, and so on. Here are the ones you’ll most often see recommended:

• Strict-Transport-Security (Strict-Transport-Security)
  Tells browsers to always use HTTPS (never downgrade to HTTP) for a given period.
  Example:

  Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  

• Content-Security-Policy (Content-Security-Policy)
  A very powerful, but complex header that lets you lock down which scripts, styles, images, fonts, frames, etc. your page is allowed to load.
  Example:

  Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com; object-src 'none'
  

• X-Frame-Options (X-Frame-Options) (largely superseded by CSP’s frame-ancestors directive, but still common)
  Prevents your pages from being embedded in iframes on other sites (click-jacking protection).
  Values: DENY, SAMEORIGIN, or ALLOW-FROM https://…

• X-Content-Type-Options (X-Content-Type-Options)
  Stops browsers from MIME-type sniffing (“if you claim it’s JSON, treat it strictly as JSON”).

  X-Content-Type-Options: nosniff
  

• Referrer-Policy (Referrer-Policy)
  Controls how much referrer information (the Referer header) the browser sends when following links or loading resources.
  Common value:

  Referrer-Policy: no-referrer-when-downgrade
  

• Permissions-Policy (formerly Feature-Policy) (Permissions-Policy)
  Lets you enable or disable powerful browser features (camera, microphone, geolocation, fullscreen, etc.) on a per-origin basis.
  Example:

  Permissions-Policy: geolocation=(), microphone=()
  

• Expect-CT (Expect-CT)
  Instructs browsers to check that your site’s certificates are logged in Certificate Transparency logs, and optionally report or block if not.

  Expect-CT: max-age=86400, enforce, report-uri="https://example.com/report"
  

• Cross-Origin-Embedder-Policy (Cross-Origin-Embedder-Policy) and Cross-Origin-Opener-Policy (Cross-Origin-Opener-Policy)
  Newer headers for isolating documents and enabling powerful browser features like SharedArrayBuffer safely.

  Cross-Origin-Opener-Policy: same-origin
  Cross-Origin-Embedder-Policy: require-corp
  

---

How you might implement this in your wrapper

1. Default Response Headers
   Whenever your RESTSpeaker wrapper finishes serializing a PHP array to JSON and sends it back to the client, have it merge in a default set of security headers like the ones above. Allow consumers to override or remove them if they really need to, but ship with a sane baseline.

2. Optional Request Headers
   If there are security-related request headers you want to send on every outgoing call (e.g. Accept: application/json, User-Agent, or some custom token header), you can do something similar on the “request” side too.

3. Configuration-Driven
   Let projects opt in or out, or tweak values, via a simple config array:

   $speaker = new RestSpeaker([
     'default_response_headers' => [
       'Strict-Transport-Security'    => 'max-age=63072000; includeSubDomains; preload',
       'X-Content-Type-Options'       => 'nosniff',
       // …
     ]
   ]);

By building these in, you help ensure that every API or web endpoint that uses your wrapper is already following modern best practices for security, without every team having to remember to paste in the same headers over and over.