> For the complete documentation index, see [llms.txt](https://support.emarketeer.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.emarketeer.com/references/developer-advanced/why-emarketeer-doesnt-support-sri-for-embed-scripts.md).

# Why eMarketeer doesn't support SRI for embed scripts

eMarketeer does not support Subresource Integrity (SRI) on its embed scripts. This article explains why.

SRI can add trust for external assets, but it also brings trade-offs — especially for a platform that delivers scripts to many customers. This article covers the reasoning and what it means for you.

## What is SRI?

Subresource Integrity (SRI) lets browsers verify that a fetched resource, such as a JavaScript file, matches an expected cryptographic hash. If the content has been altered or corrupted, the browser refuses to execute it.

## Our reasoning

After careful evaluation, here are the primary reasons we currently do not support SRI for our embed scripts:

1. Frequent updates and version agility. We continuously release improvements, security patches, optimisations, and feature enhancements. Locking each customer to a specific hash would force a manual integration update for every release, no matter how small. That approach is unsustainable at scale.
2. Lock-in risk and customer burden. SRI essentially locks the script to a fixed version. Customers must track and update the integrity value with every release, which adds maintenance burden and increases the risk of integration breakage when clients lag behind.
3. Script blocking and functional risk. If a client's integrity hash does not match — even due to minor version drift — the browser blocks the script entirely. This could disable essential features like tracking or analytics, leading to significant disruption and support overhead.
4. SRI only guards against certain threats. SRI helps protect against tampering in transit or via a compromised CDN, but it does not defend against threats earlier in the supply chain, such as a compromised build or deployment pipeline. It is not a catch-all defence.
5. Robust alternative security measures already in place. We rely on multiple layers of security to ensure safe distribution of our scripts:

   * HTTPS/TLS for secure transport.
   * Secure and audited build and deployment workflows.
   * Code reviews, access control, and internal security policies.
   * Content Security Policy (CSP) support.
   * Monitoring, auditing, and alerting on unusual activity.

   Given these layers, we currently view SRI as a maintenance burden with limited added benefit in our architecture.
6. Industry precedent. Most established platforms make explicit statements that they do not support SRI for their scripts. Their documentation notes that many services (for example Facebook, Stripe, PayPal) have similarly avoided fixed versions or SRI for their public scripts.

## What this means for you

* You can continue using our scripts without managing or rotating integrity hashes.
* We can deploy updates freely, so you receive fixes, performance improvements, and new features in a timely manner.
* We maintain strict security throughout our development and distribution processes, so the scripts delivered to you are as safe as possible.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://support.emarketeer.com/references/developer-advanced/why-emarketeer-doesnt-support-sri-for-embed-scripts.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.