chore: update links for csrf blog

public/blogs/csrf-mitigation.mdx

@@ -13,15 +13,15 @@ tags:
 ---
 
 <C>
-If you don't rely on a framework to do the heavy lifting for you, or a third party library. As I always say that you have to [understand]() the subject before you abstract it. Here's how to do it manually, but first note that none of the techniques below will work if you're already [XSS]() vulnerable
+If you don't rely on a framework to do the heavy lifting for you, or a third party library. As I always say that you have to <L href='/blog/fundamentals'>understand</L> the subject before you abstract it. Here's how to do it manually, but first note that none of the techniques below will work if you're already vulnerable to <L href='https://owasp.org/www-community/attacks/xss/'>XSS.</L>
 </C>
 <H2>Where Did The Request Come From?</H2>
 <C>
 If you do not trust the request's origin, block it.
 </C>
 <H3>"Origin" Header</H3>
 <C>
-Since the `Origin` header is being added automatically by browsers as part of the [`CORS`]() mechanism, you can check and validate the header, to check if the request that is coming in, actually comes from you site, block it if it doesn't
+Since the <L href='https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin'>`Origin`</L> header is being added automatically by browsers as part of the <L href='https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS'>`CORS`</L> mechanism, you can check and validate the header, to check if the request that is coming in, actually comes from you site, block it if it doesn't
 </C>
 <Code
   code={`if r.Header.Get("Origin") != "https://my-actual-site.com" {
@@ -34,7 +34,7 @@ Since the `Origin` header is being added automatically by browsers as part of th
 <H3>"Sec-Fetc-" Headers</H3>
 
 <C>
-Fetch Metadata headers, [introduced]() last year to provide additional context about the resource request. But all you have to know for now is you can use it  to to check the origin  
+Fetch Metadata headers, introduced last year to provide additional context about the resource request. But all you have to know for now is you can use it  to to check the origin  
 </C>
 <Code
   code={`if secFetchSite := r.Header.Get("Sec-Fetch-Site"); 
@@ -47,7 +47,7 @@ Fetch Metadata headers, [introduced]() last year to provide additional context a
   showLineNumbers={false}
 />
 <C>
-Learn more about `Sec-Fetch` headers [here](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode) and [here](https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-site-header)
+Learn more about `Sec-Fetch` headers <L href='https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode'>here</L> and <L href='https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-site-header)'>here</L>
 </C>
 <C>
 You can use a combo of these two, just to make sure, if one doesn't exist is altered the other might be used. But solely relying on headers is not sufficient, headers could potentially be tampered with or omitted due to certain browser vulnerabilities, network configurations or proxies misconfigurations. So other techniques should be employed too, like 
@@ -65,9 +65,9 @@ There  are two main ways to implement anti-CSRF tokens:
 </C>
 <H3>Stateless Services</H3>
 <C>
-As in, user sessions can be managed without a database by storing session information as a [JWT]() or [JWE]() within a [cookie](). To defend against CSRF attacks in this setup, use the "Signed Double Submit Cookie Method.": 
+As in, user sessions can be managed without a database by storing session information as a <L href='https://datatracker.ietf.org/doc/html/rfc7519'>JWT</L> or <L href='https://datatracker.ietf.org/doc/html/rfc7516'>JWE</L> within a <L href='#cookies'>cookie</L>. To defend against CSRF attacks in this setup, use the "Signed Double Submit Cookie Method.": 
 </C><C>
-This method involves generating a unique and cryptographically secure random value, typically a UUID, when a user first authenticates. This UUID is then embedded within both the payload of the JWT/JWE and the CSRF token. To ensure the integrity and authenticity of the CSRF token, use an [HMAC](https://datatracker.ietf.org/doc/html/rfc2104.html), which you combine a secret key (used for signing/encrypting the JWT/JWE) with a hash function like [Blake3](https://github.com/BLAKE3-team/BLAKE3) or SHA256 (make sure it's not computationally intensive but secure enough) , to produce a fixed-size hash value representing the message's integrity. The HMAC message includes two parts: a new random value for collision avoidance and the shared UUID between the JWT/JWE and the CSRF token. 
+This method involves generating a unique and cryptographically secure random value, typically a UUID, when a user first authenticates. This UUID is then embedded within both the payload of the JWT/JWE and the CSRF token. To ensure the integrity and authenticity of the CSRF token, use an <L href='https://datatracker.ietf.org/doc/html/rfc2104.html'>HMAC</L>, which you combine a secret key (used for signing/encrypting the JWT/JWE) with a hash function like <L href='https://github.com/BLAKE3-team/BLAKE3'>Blake3</L> or SHA256 (make sure it's not computationally intensive but secure enough) , to produce a fixed-size hash value representing the message's integrity. The HMAC message includes two parts: a new random value for collision avoidance and the shared UUID between the JWT/JWE and the CSRF token. 
 </C><C>
  The idea might **Go** like this
 </C>
@@ -243,22 +243,22 @@ Here's an AJAX example
   showLineNumbers={false}
 />
 <C>
-If you want to see a framework implementation of the synchronized pattern , check out [`Django`]()'s implementation with the CSRF mitigation middleware, you can read the source code [here]().
+If you want to see a framework implementation of the synchronized pattern , check out <L href='https://docs.djangoproject.com'>`Django`</L>'s implementation with the CSRF mitigation middleware, you can read the source code <L href='https://github.com/django/django/blob/main/django/middleware/csrf.py'>here.</L>
 </C>
-<H2>Cookies</H2>
+<H2 id='cookies'>Cookies</H2>
 <C>
 Avoid setting cookies with a specific domain to minimize security risks. When a cookie is domain-specific, all subdomains share that cookie, which can pose risks if you get hit with a <L href="https://developer.mozilla.org/en-US/docs/Web/Security/Subdomain_takeovers">subdomain takeover.</L>
 </C><C>
 For session cookies, ensure they are protected by:
 </C><C>
  - \-  Using the `HttpOnly` attribute to prevent client-side scripts from accessing cookies, enhancing security against XSS attacks.
- - \-  Setting the `SameSite` attribute to `Lax` or `Strict` to control cookie behavior in cross-site requests, more [below]().
+ - \-  Setting the `SameSite` attribute to `Lax` or `Strict` to control cookie behavior in cross-site requests, more <L href='#samesite'>below</L>.
  - \-  Avoid specifying a domain (`Domain=None`) to prevent cookies from being sent in cross-origin requests.
  - \-  Using the `Secure` attribute to ensure that cookies are only sent over HTTPS connections.
 </C><C>
-Also, for enhanced security measures, consider cookie prefixes like `__Host-` and `__Secure-`, read more [here]()
+Also, for enhanced security measures, consider cookie prefixes like `__Host-` and `__Secure-`, read more <L href='https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-cookie-prefixes-00'>here.</L>
 </C>
-<H3>About "SameSite" Cookies</H3>
+<H3 id="#samesite">About "SameSite" Cookies</H3>
 <C>
 Use the `SameSite` cookie attribute to set your users sessions (older browsers do not support this)
 </C>
@@ -276,7 +276,7 @@ Or
   showLineNumbers={false}
 />
 <C>
-Read about [`Lax`]() and [`Strict`]() from the official [RFC](). Here's is basically what they do:
+Read about `Lax` and `Strict` from the official <L href='https://datatracker.ietf.org/doc/html/draft-west-first-party-cookies-07'>RFC</L>. Here's is basically what they do:
 </C>
 <C>
 **``Strict``:** This value prevents cookies from being sent in all cross-site browsing contexts, including regular links. For example: You're logged in your banking account, which means you have a session cookie. If this banking website employs the Strict ``SameSite`` value for its session cookies, and you  click on a link to perform a banking transaction from an external website (like a forum or email) say https://scam-me-please.com , the banking website won't receive the session cookie due to the ``Strict`` setting. Consequently, the user won't be able to complete the transaction because the session information is not sent with the request. 
@@ -288,9 +288,9 @@ Read about [`Lax`]() and [`Strict`]() from the official [RFC](). Here's is basic
 <H2>User Interaction-Based CSRF Defense</H2>
 
 <C>
-Requiring users to authenticate using their password, biometric data, security questions, or [OTP]() is a highly effective security measure. However, it can significantly impact user experience, so it's typically used only for critical operations like changing passwords or conducting financial transactions. Avoid using CAPTCHA for this purpose, as it's primarily aimed at preventing automated bot attacks and doesn't provide the necessary level of security for these sensitive activities.
+Requiring users to authenticate using their password, biometric data, security questions, or <L href="https://en.wikipedia.org/wiki/One-time_password">OTP</L> is a highly effective security measure. However, it can significantly impact user experience, so it's typically used only for critical operations like changing passwords or conducting financial transactions. Avoid using CAPTCHA for this purpose, as it's primarily aimed at preventing automated bot attacks and doesn't provide the necessary level of security for these sensitive activities.
 </C>
 <H2>HTTP Methods</H2>
 <C>
-And oh yeah, did I mention that for any state changing request,  DON'T USE  [safe methods]().
+And oh yeah, did I mention that for any state changing request,  DON'T USE  <L href='https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.1'>safe methods.</L>
 </C>