xsleaks · vikvanderlinden · May 9, 2025 · May 9, 2025
diff --git a/content/docs/attacks/cache-probing.md b/content/docs/attacks/cache-probing.md
@@ -38,13 +38,13 @@ Cache Probing with [Error Events]({{< ref "../attacks/error-events.md" >}}) [^2]
 
 1. [Invalidating the resource]({{< ref "#invalidating-the-cache" >}}) from the browser cache. This step is required to make sure the attack does not consider a resource previously cached in another visit.
 2. Performing a request that causes different items to be cached depending on the user's state. For example, loading a page that includes a specific image only if the user is logged in. This request can be triggered by navigating to the target website with `<link rel=prerender..`, embedding the website in an `iframe`, or opening a new window with `window.open`.
-3. Triggering a request that causes the server to reject the request. For example, including an [overlong referer header](https://lists.archive.carbon60.com/apache/users/316239) that  makes the server reject the request. If the resource was cached in step 2, this request succeeds instead of triggering an error event.
+3. Triggering a request that causes the server to reject the request. For example, including an [overlong referer header](https://web.archive.org/web/20240228130427/https://lists.archive.carbon60.com/apache/users/316239) that  makes the server reject the request. If the resource was cached in step 2, this request succeeds instead of triggering an error event.
 
 ### Invalidating the cache with errors
 
 To invalidate a resource from the cache, the attacker must force the server to return an error when fetching that subresource. There are a couple of ways to achieve this:
 
-- A request with an [overlong referer header](https://lists.archive.carbon60.com/apache/users/316239) and `'cache':'reload'`. This might not work as browsers [capped](https://github.com/whatwg/fetch/issues/903) the length of the referrer to prevent this.
+- A request with an [overlong referer header](https://web.archive.org/web/20240228130427/https://lists.archive.carbon60.com/apache/users/316239) and `'cache':'reload'`. This might not work as browsers [capped](https://github.com/whatwg/fetch/issues/903) the length of the referrer to prevent this.
 - Request headers such as Content-Type, Accept, Accept-Language, etc. that may cause the server to fail (more application dependent).
 - Other request properties.
 
@@ -63,7 +63,7 @@ It's also possible to remove resources from cache without server errors. For exa
 Origin reflection is a behavior in which a globally accessible resource is provided with a [Access-Control-Allow-Origin (ACAO)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin) header whose value reflects the origin that initialized the request. This can be considered as CORS misconfiguration [^5] and can be used to detect whether the resource exists in the browser cache.
 
 {{< hint info >}} 
-For example, Flask framework [promotes](https://flask-cors.readthedocs.io/en/latest/api.htm) origin reflection as the default behavior.
+For example, Flask framework [promotes](https://flask-cors.readthedocs.io/en/latest/api.html) origin reflection as the default behavior.
 {{< /hint >}}
 
 If a resource hosted on `server.com` is requested from `target.com` then the origin could be reflected in the response headers as: `Access-Control-Allow-Origin: target.com`. If the resource is cached, this information is stored together with the resource in the browser cache. With that, if `attacker.com` tries to fetch the same resource there are two possible scenarios:
@@ -172,5 +172,5 @@ An attacker using [Error Events Cache Probing]({{< ref "#cache-probing-with-erro
 [^1]: Abusing HTTP Status Codes to Expose Private Information, [link](https://www.grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information)
 [^2]: HTTP Cache Cross-Site Leaks, [link](http://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html)
 [^3]: Mass XS-Search using Cache Attack, [link](https://terjanq.github.io/Bug-Bounty/Google/cache-attack-06jd2d2mz2r0/index.html#VIII-YouTube-watching-history)
-[^4]: Timing Attacks on Web Privacy, [link](http://www.cs.jhu.edu/~fabian/courses/CS600.424/course_papers/webtiming.pdf)
+[^4]: Timing Attacks on Web Privacy, [link](https://www.cs.jhu.edu/~rubin/courses/fall03/papers/timing.pdf) ([alt](https://web.archive.org/web/20220726203115/https://www.cs.jhu.edu/~fabian/courses/CS600.424/course_papers/webtiming.pdf))
 [^5]: CORS misconfiguration, [link](https://web-in-security.blogspot.com/2017/07/cors-misconfigurations-on-large-scale.html)
diff --git a/content/docs/attacks/css-injection.md b/content/docs/attacks/css-injection.md
@@ -41,7 +41,7 @@ Optionally include the sandbox attribute to isolate the content into its own ori
 | :--------------------------------------------------------------------------------: | :-------------------------------------------------: | :---------------------------------------------------------------: | :-------------------------------------------------------------------: |
 |                                         ❌                                          |                          ❌                          |                                 ❌                                 |                                   ❌                                   |
 ## References
-[^1]: CSS Injection Primitives, [link](https://x-c3ll.github.io/posts/CSS-Injection-Primitives/)
+[^1]: CSS Injection Primitives, [link](https://x-c3ll.github.io/posts/2019/10/16/CSS-Injection-Primitives.html) ([alt](https://web.archive.org/web/20240619225434/https://x-c3ll.github.io/posts/CSS-Injection-Primitives/))
 [^2]: HTTPLeaks, [link](https://github.com/cure53/HTTPLeaks/)
 [^3]: Font ligatures, [link](https://research.securitum.com/stealing-data-in-great-style-how-to-use-css-to-attack-web-application/)
 [^4]: Chrome tab crashes when using gradients in display-p3, rec2020, prophoto-rgb or a98-rgb, [link](https://issues.chromium.org/issues/382086298)

diff --git a/content/docs/attacks/css-tricks.md b/content/docs/attacks/css-tricks.md
@@ -93,10 +93,9 @@ This can be done by disabling the browser history, or if on Firefox, by setting
 | :--------------------------------------------------------------------------------: | :-------------------------------------------------: | :---------------------------------------------------------------: | :-------------------------------------------------------------------: |
 |                                         ❌                                          |                          ❌                          |                                 ✔️                                 |                                   ❌                                   |
 ## References
-[^leak-1]: Whack a mole game, [link](https://lcamtuf.coredump.cx/whack/)  
 [^changes-1]: Privacy and the :visited selector, [link](https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector)  
 [^blend-mode]: CSS mix-blend-mode is bad for your browsing history, [link](https://lcamtuf.blogspot.com/2016/08/css-mix-blend-mode-is-bad-for-keeping.html)  
-[^render-timings]: Pixel Perfect Timing Attacks with HTML5, [link](https://owasp.org/www-pdf-archive/HackPra_Allstars-Browser_Timing_Attacks_-_Paul_Stone.pdf)  
+[^render-timings]: Pixel Perfect Timing Attacks with HTML5, [link](https://wiki.owasp.org/images/1/10/HackPra_Allstars-Browser_Timing_Attacks_-_Paul_Stone.pdf) ([alt](https://web.archive.org/web/20231226222431/https://owasp.org/www-pdf-archive/HackPra_Allstars-Browser_Timing_Attacks_-_Paul_Stone.pdf))  
 [^exploit-1]: XS-Leaking flags with CSS: A CTFd 0day, [link](https://jorianwoltjer.com/blog/p/hacking/xs-leaking-flags-with-css-a-ctfd-0day)  
 [^render-timings-bug]: Visited links can be detected via redraw timing, [link](https://bugs.chromium.org/p/chromium/issues/detail?id=252165)
 [^leak-2]: The Human Side Channel, [link](https://ronmasas.com/posts/the-human-side-channel)  
diff --git a/content/docs/attacks/element-leaks.md b/content/docs/attacks/element-leaks.md
@@ -148,6 +148,6 @@ The below code embeds `//example.org/404` and if it responds with *Error* then a
 ## References
 [^script-leaks]: The Unexpected Dangers of Dynamic JavaScript. [link](https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-lekies.pdf)   
 [^fallback]: HTML Standard, [3.2.5.2.6 Embedded content], [link](https://html.spec.whatwg.org/multipage/dom.html#fallback-content)  
-[^leaky-images]: Leaky Images: Targeted Privacy Attacks in the Web, [3.4 Linking User Identities], [link](https://www.usenix.org/system/files/sec19fall_staicu_prepub.pdf)  
+[^leaky-images]: Leaky Images: Targeted Privacy Attacks in the Web, [3.4 Linking User Identities], [link](https://www.usenix.org/system/files/sec19-staicu.pdf)  
 [^xsleaks-nojs]: [https://twitter.com/terjanq/status/1180477124861407234](https://twitter.com/terjanq/status/1180477124861407234)  
 [^pdf-api]: pdf_viewer.ts, [link](https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/resources/pdf/pdf_viewer.ts)  
diff --git a/content/docs/attacks/historical/content-type.md b/content/docs/attacks/historical/content-type.md
@@ -19,7 +19,7 @@ Leaking the Content-Type of a request would provide attackers with a new way of
 
 ## typeMustMatch
 
-[`typeMustMatch`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLObjectElement/typeMustMatch) is a Boolean that reflects the `typeMustMatch` attribute of the `object` element. It ensures that a certain MIME type must be enforced when loading an object, by verifying if the `Content-Type` of the resource is the same as the one provided in the object. Unfortunately, this enforcement also allowed attackers to leak the `Content-Type` and Status Codes returned by a website [^1].
+[`typeMustMatch`](https://web.archive.org/web/20210421092442/https://developer.mozilla.org/en-US/docs/Web/API/HTMLObjectElement/typeMustMatch) is a Boolean that reflects the `typeMustMatch` attribute of the `object` element. It ensures that a certain MIME type must be enforced when loading an object, by verifying if the `Content-Type` of the resource is the same as the one provided in the object. Unfortunately, this enforcement also allowed attackers to leak the `Content-Type` and Status Codes returned by a website [^1].
 
 ### Root Cause
 

diff --git a/content/docs/attacks/id-attribute.md b/content/docs/attacks/id-attribute.md
@@ -52,7 +52,11 @@ Some examples of `id`-attribute-based attacks are:
 
 ## Defense
 
-{{< hint info>}} As of September 2022, an experiment called Portals exists that could allow the attack to work with Framing Protections [^2] {{< /hint >}}
+{{< hint info>}}
+As of September 2022, an experiment called Portals exists that could allow the attack to work with Framing Protections [^2]
+
+[^2]: Detecting IDs using Portal, [link](https://portswigger.net/research/xs-leak-detecting-ids-using-portal)
+{{< /hint >}}
 
 | [Document Policies]({{< ref "/docs/defenses/opt-in/document-policies.md" >}}) | [SameSite Cookies (Lax)]({{< ref "/docs/defenses/opt-in/same-site-cookies.md" >}}) | [COOP]({{< ref "/docs/defenses/opt-in/coop.md" >}}) | [Framing Protections]({{< ref "/docs/defenses/opt-in/xfo.md" >}}) |                                          [Isolation Policies]({{< ref "/docs/defenses/isolation-policies" >}})                                          |
 | :--------------------------------------------------------------------------------: | :--------------------------------------------------------------------------------: | :-------------------------------------------------: | :---------------------------------------------------------------: | :-----------------------------------------------------------------------------------------------------------------------------------------------------: |
@@ -62,4 +66,3 @@ Some examples of `id`-attribute-based attacks are:
 ## References
 
 [^1]: Leaking IDs using focus, [link](https://portswigger.net/research/xs-leak-leaking-ids-using-focus)
-[^2]: Detecting IDs using Portal, [link](https://portswigger.net/research/xs-leak-detecting-ids-using-portal)
diff --git a/content/docs/attacks/timing-attacks/execution-timing.md b/content/docs/attacks/timing-attacks/execution-timing.md
@@ -25,7 +25,7 @@ Measuring the time of JavaScript execution in a browser can give attackers infor
 
 ## Timing the Event Loop
 
-JavaScript's concurrency model is based on a [single-threaded event loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop) which means it can only run one task at a time. If, for example, some time-consuming task blocks the event loop, the user can perceive a freeze on a page as a result of the UI thread being starved. Other tasks must wait until the blocking task finishes. Each browser implements different [process models](https://www.chromium.org/developers/design-documents/process-models), which means some web sites might run in different threads (and event loops) depending on their relations.
+JavaScript's concurrency model is based on a [single-threaded event loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop) which means it can only run one task at a time. If, for example, some time-consuming task blocks the event loop, the user can perceive a freeze on a page as a result of the UI thread being starved. Other tasks must wait until the blocking task finishes. Each browser implements different [process models](https://chromium.googlesource.com/chromium/src/+/main/docs/process_model_and_site_isolation.md), which means some web sites might run in different threads (and event loops) depending on their relations.
 
 Some techniques can exploit this model to steal secrets from a cross-origin page:
 

diff --git a/content/docs/attacks/xs-search.md b/content/docs/attacks/xs-search.md
@@ -55,4 +55,4 @@ If both behaviors above can be distinguished by a more reliable XS-Leak than tim
 ## References
 
 [^1]: Cross-Site Search Attacks, [link](https://446h.cybersec.fun/xssearch.pdf)
-[^2]: Cross-Site Search (XS-Search) Attacks - Hemi Leibowitz, OWASP AppSec IL 2015, [link](https://owasp.org/www-pdf-archive/AppSecIL2015_Cross-Site-Search-Attacks_HemiLeibowitz.pdf)
+[^2]: Cross-Site Search (XS-Search) Attacks - Hemi Leibowitz, OWASP AppSec IL 2015, [link](https://wiki.owasp.org/images/a/a7/AppSecIL2015_Cross-Site-Search-Attacks_HemiLeibowitz.pdf) ([alt](https://web.archive.org/web/20231226222426/https://owasp.org/www-pdf-archive/AppSecIL2015_Cross-Site-Search-Attacks_HemiLeibowitz.pdf))   
diff --git a/content/docs/contributions/_index.md b/content/docs/contributions/_index.md
@@ -44,7 +44,7 @@ You can run a local environment by following these steps:
 We use the [Hugo Book Theme](https://themes.gohugo.io/hugo-book/) with custom modifications.
 
 ### Custom hint shortcode
-We modified the default [Hints](https://themes.gohugo.io/theme/hugo-book/docs/shortcodes/hints/) used by the theme; the modified boxes are listed below:
+We modified the default [Hints](https://hugo-book-demo.netlify.app/docs/shortcodes/hints/) used by the theme; the modified boxes are listed below:
 
 {{< hint info >}}
 This is an *Info* box for the `{{</*/* hint info */*/>}}` shortcode.
@@ -89,7 +89,8 @@ We would like to thank the following users who [contributed](https://github.com/
 [Brasco](https://github.com/Brasco/), [rick.titor](https://github.com/riccardomerlano),
 [Chris Fredrickson](https://github.com/cfredric/), [jub0bs](https://github.com/jub0bs),
 [Zeyu (Zayne) Zhang](https://github.com/zeyu2001), [Medi](https://twitter.com/medi_0ne), 
-[Aaron Shim](https://github.com/aaronshim), [Jorian Woltjer](https://jorianwoltjer.com)
+[Aaron Shim](https://github.com/aaronshim), [Jorian Woltjer](https://jorianwoltjer.com),
+[Vik Vanderlinden](https://vikvanderlinden.be/)
 
 In addition, we would also like to acknowledge the users who [contributed](https://github.com/xsleaks/xsleaks/wiki/Browser-Side-Channels/_history) to the predecessor of the current XS-Leaks wiki:
 

diff --git a/content/docs/defenses/opt-in/fetch-metadata.md b/content/docs/defenses/opt-in/fetch-metadata.md
@@ -8,7 +8,7 @@ category = [
 menu = "main"
 +++
 
-[Fetch Metadata Request Headers](https://www.w3.org/TR/fetch-metadata/) are sent by browsers with HTTPS requests. These headers provide context on how a request was initiated so that applications are able to make more informed decisions on how to respond to them. This allows servers to behave differently when they detect potential attacks (e.g. unexpected cross-origin requests)[^1]. This can be very effective against cross-origin attacks like XSSI, XS-Leaks, Clickjacking, and CSRF if a strict policy is deployed on the server.
+[Fetch Metadata Request Headers](https://www.w3.org/TR/fetch-metadata/) are sent by browsers with HTTPS requests. These headers provide context on how a request was initiated so that applications are able to make more informed decisions on how to respond to them. This allows servers to behave differently when they detect potential attacks (e.g. unexpected cross-origin requests). This can be very effective against cross-origin attacks like XSSI, XS-Leaks, Clickjacking, and CSRF if a strict policy is deployed on the server.
 
 In the XS-Leaks scenario, servers have the ability to know when a request was made cross-origin (e.g. attacker origin) and can return a different response with no user data. This kind of response is not useful to the attacker since it does not carry any information or state about the user. Fetch Metadata can also be used to block framing or even navigational requests.