c/side is a cyber security product that lives in the browser supply chain space. We and other vendors operating here, like to talk about that supply chain. But, what do we exactly mean by it?
The browser supply chain is the combination of components and processes that come together to render web pages, execute scripts, and ensure smooth functionality. This supply chain includes everything from the initial request for a webpage to the final rendering of that page in a user's browser. As well as dynamic behaviours that happen after the site is rendered.
Here’s the full browser supply chain and how to secure it correctly
1. The user takes action: A user initiates a request by entering a URL in the browser or clicking a link.
Components: Browser.
2. DNS Resolution: The browser queries a DNS server to translate the domain name into an IP address.
Components: DNS servers and browser cache.
Use DNSSEC (Domain Name System Security Extensions) to secure the DNS lookup process. This validates the authenticity of the DNS response, protecting against DNS spoofing and cache poisoning attacks. While DNS caching can enhance load times, make sure the TTL of a DNS record is set low enough so that you can make changes quickly. Lastly, opt for DNS providers that have a strong security track record.
3. TCP/IP Connection: The browser establishes a TCP connection to the web server using the IP address obtained from the DNS resolution.
Components: Internet infrastructure, ISP and network routers.
Configure network layer firewalls to monitor and control both inbound and outbound network traffic based on security policies. This helps in preventing unauthorized access.
4. SSL/TLS Handshake: If the connection is secure (HTTPs), the browser and server perform an SSL/TLS handshake to establish an encrypted connection.
Components: SSL/TLS certificates and Certificate Authorities (CAs).
Always use Transport Layer Security (TLS) to encrypt data transmitted over the network. This prevents attackers from eavesdropping or tampering with the data in transit.
5. HTTP Request: The browser sends an HTTP request to the server for the web page.
Components: Web server and load balancers.
Implement HTTPS on all your pages to secure HTTP requests by encrypting data in transit. Use HTTP Strict Transport Security (HSTS) to guarantee that browsers only establish secure connections with your server. If applicable, consider implementing rate limiting to prevent abuse of your service's APIs.
6. Server Response: The server processes the request and responds with an HTML document and associated JavaScript. Often the delivery of the initial response will trigger the browser to fetch content from other 3rd party servers. However, the responses here can be dynamic so it is recommended to have a tool like c/side in place to keep an eye on the client-side fetched 3rd party resources.
Components: Web server, application server and database server.
To prevent Cross-Site Scripting (XSS) attacks, properly encode any user-generated content in server responses. This involves transforming potentially harmful characters into safe encoded equivalents before returning them to the client.
7. Content Delivery Networks (CDNs): Static assets like images, CSS, and JavaScript files are often served from CDNs to reduce latency.
Components: CDN servers.
Many people believe that securing the browser supply chain only requires securing the beginning of the line. However, this assumption is incorrect. Our launch campaign, Supply Chain Risk Doesn’t End At NPM, elaborates on why this is not the case. Just securing this aspect is insufficient, as demonstrated by the 2021 incident with cdnjs. Despite being used on 12% of all global websites, cdnjs was open to a significant vulnerability.
So here, using a robust CDN provider is of course needed. Just make sure it’s not your only safety barrier and you follow the other recommendations.
8. HTML Parsing and Rendering: The browser parses the HTML document to build the DOM (Document Object Model).
Components: Browser rendering engine.
In a similar way, don’t solely rely on Content Security Policies (CSPs), but set them up here. If inline scripts are necessary, use a nonce (a one-time token) in the script tag. The nonce should match the one in the Content Security Policy (CSP) header. This approach ensures that only scripts with the correct nonce can execute, which helps prevent unauthorized or malicious scripts from running.
9. CSS Parsing: The browser parses the CSS files to construct the CSSOM (CSS Object Model).
Components: Browser rendering engine.
CSS expressions can execute code in the browser context, potentially leading to security vulnerabilities. Even though they are largely obsolete and unsupported in many modern browsers. If your application allows users to input CSS directly or indirectly (through a CMS or similar), ensure that this input is validated and sanitized to prevent malicious CSS from being executed. This can include stripping out JavaScript-based URLs, expressions, and potentially harmful properties.
10. JavaScript Execution and Third-Party Scripts: The browser downloads and executes JavaScript files, modifying the DOM and CSSOM as necessary. Additional scripts from third-party sources (e.g., analytics, ads, social media widgets) are fetched and executed.
Components: Browser JavaScript Engine, Third-party servers, Content Security Policy (CSP) settings and c/side.
We process all third-party scripts through our detection engine, enhancing their speed to avoid any added latency. We provide you with this data, enabling you to monitor their activity, which is crucial for compliance with PCI DSS 4.0 regulations. We can also autonomously block malicious actors, increasing your website's safety. Start with us for free today to be closer to compliance and safer right away.
For other vendors and how we shape up, read here.
11. Resource Fetching: The browser makes additional HTTP requests for resources referenced in the HTML, CSS, and JavaScript (e.g., fonts, additional images).
Components: Web server and CDN.
Important to note here, is that c/side catches any malicious activity in the third-party domain before it gets rendered by the browser. Other monitoring tools often do not do this. In our opinion, this is the best way to secure this.
12. Client-Side Caching: The browser caches resources locally to improve performance on subsequent visits.
Components: Browser cache and Service Workers.
Set suitable cache directives to avoid storing sensitive information in the cache. For especially sensitive pages, use the no-store directive to ensure they are not cached. Always use HTTPS for all transactions. Implement checksums or hashes to verify the integrity of cached data before it is used.
13. Service Workers: If applicable, service workers can intercept network requests, manage caching, and enable offline functionality.
Components: Service Worker scripts and browser environment.
Set strict caching rules in your service worker scripts to ensure that only non-sensitive, unchanging content is cached.
14. Rendering and Painting: The browser constructs the render tree and paints the pixels to the screen, creating the visual representation of the web page.
Components: Browser rendering engine (and GPU).
Ensure that resources loaded from cross-origin sources are not able to interfere with the rendering of your site. Use the crossorigin attribute to control how these resources interact with your document.
15. User Interaction Step: The user interacts with the web page (e.g., clicking, typing), triggering event listeners and further script execution.
Components: Browser DOM, event handling mechanisms and JavaScript engine.
Implement anti-CSRF tokens in forms to guard against Cross-Site Request Forgery attacks. Make sure JavaScript event handlers are securely coded to prevent exposure of sensitive information or functionality. Avoid using inline JavaScript in HTML attributes such as onclick. If your site permits file uploads, ensure thorough malware scanning of uploaded files. Apply strict size and type restrictions to prevent uploads of potentially harmful files.
Get your supply chain as safe as possible.
We urge you to begin this process today. Many organizations have experienced attacks, fines, or reputation damage due to neglecting their web supply chain security. This often stems from compliance issues related to not securing sites to set standards.
Standards change frequently, usually in response to attacks or identified issues. Proactively address these potential problems by going the extra mile today. Use the comprehensive list provided above to secure each part of your supply chain to the highest degree possible.
Also, consider using c/side. With our free tier, you can monitor and secure third-party scripts on your site, ensuring that part of your website is completely secure.