Subresource Integrity (SRI)

Subresource Integrity is a project: we add integrity (hash) and crossorigin attributes to included third-party resources (scripts/styles from a CDN, libraries), so the browser verifies file integrity and does NOT execute it if the content changed (was substituted). Honestly about the scope, this is key: SRI protects against a SPECIFIC risk — substitution/compromise of an included third-party file (CDN hack, supply-chain at the file-delivery level): if the file is substituted, the hash will not match and the browser will not execute it. This is a useful but NARROW measure: it does NOT protect against XSS in your code, against vulnerabilities in the library itself (if substituted it will not execute, but if the original has a hole, SRI will not close it), and does not replace CSP. Honestly about the versioning limit, important: SRI works only for STATIC, versioned resources with fixed content — if a third-party script auto-updates at the same URL (like some widgets/analytics), the hash will stop matching and the resource will BREAK; so SRI is not applicable to everything (e.g. not to self-updating analytics) — we honestly note what it is applicable to. Honestly about maintenance: when updating a library the hash must be updated too, otherwise the resource will stop loading. Honestly about access: access to the code/templates is needed. Honestly about the effect: it closes the substitution risk of included files, we do NOT guarantee sales growth by itself. An important boundary: this is SRI (integrity of included files), not CSP (754 — sources), not XSS protection (752) and not a library audit. Picture this: instead of 'a script substituted on the CDN executes for everyone' — the browser rejects the changed file. The base price starts from 9,000 ₽ per project; it depends on the number of included resources.

• Third-party scripts/styles are included without integrity verification.
• Risk of executing code substituted via CDN/supply-chain.
• There is no protection against compromise of external library delivery.
• You do not know which resources can be protected via SRI.

• Adding integrity hashes and crossorigin to static resources
• Determining which resources SRI applies to (and which not)
• Correct handling of self-hosted and versioned files
• Accounting for self-updating resources (where SRI would break)
• Checking that nothing broke
• Recommendations on updating hashes when updating libraries
• Indicating boundaries (a narrow measure, not a CSP/anti-XSS replacement)
• Handover and review with you

• Substituted included files do not execute
• Protection against compromise of external library delivery
• Applied where it is safe (without breakage)
• A narrow but real barrier (all protection — in combination)

• We inventory included resources; collect code access
• We add hashes where applicable; exclude self-updating ones
• We verify operation, give update recommendations, review with you

• Will SRI protect my site from being hacked?

  Only against a specific risk — substitution/compromise of an included third-party file (CDN hack). It is a narrow measure: it does not protect against XSS in your code, against holes in the library itself and does not replace CSP. Useful in combination with other measures.

• Can SRI be put on all scripts?

  No. SRI works only for static versioned files with fixed content. If a third-party script auto-updates at the same URL (some analytics/widgets), the hash will stop matching and the resource will break. We apply it selectively, to suitable ones.

• What about when updating a library?

  The integrity hash must be updated too, otherwise the updated file will not load (hash mismatch). It is maintenance: when updating versions the hashes are recomputed. We leave recommendations so it does not break the site.