📌
Software Security
  • README
  • Prerequisites
    • Prerequisites
  • Introduction
    • Cyber security principles
    • Basic web concepts
      • HTTP
      • JavaScript
      • Cookies
      • SQL
      • DOM
      • APIs and the multitier architecture
    • Basic browser security concepts
      • Same-Origin Policy (SOP)
      • Cross-Origin Resource Sharing (CORS)
      • Cookies
      • Tracking
    • Basic security concepts
      • Hashing
  • Access Control: Basics
    • Authentication
      • Passwords
      • Password managers
      • Attacking passwords - online
      • Attacking passwords - offline
    • Authorization
      • Insecure direct object references
    • Session Management
    • CSRF
      • CSRF: why & how it works
      • Protecting against CSRF attacks
    • SSRF
      • SSRF: how it works and how we can protect against it
  • Access Control: Advanced
    • Authentication
      • Federation
      • Alternative authentication mechanisms
      • FIDO2 and WebAuthn
  • Injection attacks
    • Injection attacks
    • SQL Injection
    • Command Injection
    • Cross-site scripting
      • Input validation
      • Context sensitive output encoding
      • About the HttpOnly flag
      • Content Security Policy
    • Subresource integrity
    • Sandboxing
  • HTTPS
    • HTTPS
    • Introduction to cryptography
    • PKI
    • Setting up HTTPS
    • References
  • HTTP Headers for security
    • HTTP Headers
  • Threat Modeling
    • Threat modeling introduction
    • Threat modeling basics
    • Inspiration for threats
  • Bringing it all together
    • A comprehensive overview of controls
Powered by GitBook
On this page
  • Subresource integrity
  • Protecting third party resources
  • Source attribution

Was this helpful?

  1. Injection attacks

Subresource integrity

PreviousContent Security PolicyNextSandboxing

Last updated 3 years ago

Was this helpful?

Subresource integrity

Often, scripts from third party providers are used. For example, your HTML head may look like this:

<head>
<script src="https://code.jquery.com/jquery-3.4.1.min.js" crossorigin="anonymous"></script>
<script src='https://www.google-analytics.com/analytics.js'></script>
</head>

In case the servers hosting these JavaScript libraries are compromised, all webites using this library will run malicious scripts.

Protecting third party resources

Subresource Integrity allows web developers to ensure that resources hosted on third-party servers have not been tampered with. Always try to use SRI whenever libraries are loaded from a third-party source. The idea is simple, instead of using the following script reference:

<script src="https://code.jquery.com/jquery-3.4.1.min.js" crossorigin="anonymous"></script>

You should use the following:

<script src="https://code.jquery.com/jquery-3.4.1.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script>

This latter reference has an integrity attribute (integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=) which basically is a hash of the JQuery script. In case an attacker is able to modify the JQuery script, your browser will not load it anymore since the browser will verify that the hash of the JQuery script equals the value of the integrity attribute.

Source attribution

Some parts of this page are based on the , which is licensed under .

Third Party Javascript Management Cheat Sheet
FLOSS