Loading

Security Headers in Salesforce: What Really Matters

Fecha de publicación: Oct 9, 2025
Descripción

At Salesforce, customer Trust is our #1 value. We've frequently observed "missing security headers" or "cookies missing attributes" being identified as vulnerabilities in customer security reviews and penetration test reports

Security headers are a vital defense mechanism, but their application is context-dependent. Not every response requires every header, as their value varies across scenarios. Like traffic signs, not all headers are relevant or appropriate in every situation.

This article will clarify the purpose of common headers, how they are managed by Salesforce products (including Sales Cloud, Service Cloud, Marketing Cloud, Tableau, and Commerce Cloud), and explain why the deliberate omission of certain headers does not compromise security.

We’ll focus on Salesforce products most often mentioned in customer security scans:
Salesforce Core (Sales/Service Cloud, Lightning, VisualForce), Marketing Cloud, Tableau, and Commerce Cloud (B2C Commerce). 

The same principle applies platform-wide: headers are applied thoughtfully, in the right places, based on security needs, not simply everywhere for coverage.

Solución

Common Security Headers and What They Do:

 

1. Strict-Transport-Security (HSTS):

  • What it does: Instructs browsers to always use HTTPS, never HTTP. Prevents downgrade attacks to insecure channels.

  • How Salesforce uses it: All Salesforce core domains (login.salesforce.com, Lightning, Visualforce) already enforce HTTPS at the platform edge. Even if someone tries HTTP, Salesforce redirects to HTTPS.

  • Why it’s not always required: On non-customer-facing or internal endpoints, repeating HSTS is unnecessary since HTTPS-only is already enforced. Think of it as a building-wide security guard, you don’t need one at every door.

2. X-Frame-Options / Frame-Ancestors (Clickjacking Protection):

  • What it does: Prevents attackers from embedding your page in a hidden frame to trick users into unsafe clicks.

  • How Salesforce uses it: Sensitive interfaces having single/multi click pages enforce this protection.

  • Why it’s not always required: Not all resources are susceptible to clickjacking. For example, raw data (like API responses or JSON feeds) has no interactive elements, so applying this header doesn’t improve security.

3. X-Content-Type-Options (NoSniff):

  • What it does: Prevents browsers from “sniffing” file types (e.g., misinterpreting an image as code).

  • How Salesforce uses it: Applied where mixed content might exist to ensure files are handled strictly.

  • Why it’s not always required: Endpoints having structured content (like JSON), static pages, pages where user-input is not being reflected back are not vulnerable to content-sniffing attacks.

4. Referrer-Policy:

  • What it does: Controls how much information about the previous page is shared when a user clicks a link.

  • How Salesforce uses it: In Salesforce Core, admins can configure this behavior.

  • Why it’s not always required: If a page doesn’t send users to external domains, referrer information isn’t relevant.

5. Content-Security-Policy (CSP):

  • What it does: A powerful defense against cross-site scripting (XSS), defining which scripts, images, or styles are allowed.

  • How Salesforce uses it: Enforced on Lightning Experience and other secure UI pages to block untrusted sub-resources.

  • Why it’s not always required: Static assets or APIs that don’t execute code don’t benefit from CSP.

6. Cookie Attributes (Secure, HttpOnly, SameSite):

  • What they do: Strengthen cookie handling, Secure enforces HTTPS-only, HttpOnly blocks JavaScript access, and SameSite limits cross-site usage.

  • How Salesforce uses them: Sensitive cookies like authentication and session tokens always use Secure and HttpOnly.

  • Why it’s not always required: Non-sensitive cookies (e.g., tracking) have looser policies depending on intended use.

 

Salesforce Products: Where Headers Matter

 

1. Core Platform (Sales Cloud, Service Cloud, Lightning, Visualforce):

  • HSTS is enforced on all core domains (login.salesforce.com, MyDomain, Lightning, Visualforce).

  • For Standard out-of-the box Salesforce pages, Clickjacking protection is set automatically [via CSP or x-frame-options] and cannot be disabled. For Visualforce pages, an option to enable/disable clickjacking protection is provided.

  • CSP is applied to Lightning and Visualforce on a need-to-have basis as mentioned above.

2. Marketing Cloud:

  • Security Headers API allows configuration of CSP, HSTS, X-Frame-Options, Referrer-Policy, and more.

  • CloudPages support custom header injection.

3. Commerce Cloud (B2C Commerce):

  • HSTS can be enforced for storefront traffic

  • X-Frame-Options supported from version 13.3 onward.

4. Tableau (with Salesforce):

  • Embedded Tableau in Salesforce inherits Salesforce platform protections (HTTPS, X-Frame-Options).

  • Tableau Server/Online allows admins to configure headers directly.

The Key Message

  • A missing header does not always mean vulnerability.

  • Salesforce applies headers deliberately where they add security value.

  • Automated scanner findings often mislabel missing headers as risks, when in reality they are non-issues in most scenarios

  • Customers should only be concerned if:

    • Sensitive pages (login, setup, transactions) lack expected protections (HSTS, CSP, anti-clickjacking headers).

    • Authentication/session cookies lack Secure or HttpOnly.




Número del artículo de conocimiento

005225194

 
Cargando
Salesforce Help | Article