Bug: Code block rendering issue on the website

[johnbillion]

Under section 1.1 of https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#how-to-treat-fetch-metadata-headers-on-the-server-side there is a rendering issue with the code blocks. Three successive code blocks are merged into one, and the headings between them are rendered as code.

Source file:

CheatSheetSeries/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md

Lines 192 to 239 in 7a75595

	1. If `Sec-Fetch-Site` is present
	1.1. Treat cross-site as untrusted for state-changing actions. By default, reject non-safe methods (POST / PUT / PATCH / DELETE) when `Sec-Fetch-Site: cross-site`.
	```JavaScript
	const SAFE_METHODS = new Set(['GET','HEAD','OPTIONS']);
	const site = req.get('Sec-Fetch-Site'); // e.g. 'cross-site','same-site','same-origin','none'
	if (site === 'cross-site' && !SAFE_METHODS.has(req.method)) {
	return false; // forbid this request
	}
	```
	1.2 If your application relies on [safe HTTP methods](https://developer.mozilla.org/en-US/docs/Glossary/Safe/HTTP) (GET, HEAD, or OPTIONS) for state‑changing actions, you should explicitly reflect that in your policy – e.g., by requiring a Fetch‑Metadata header review for requests to those endpoints. This can be enforced with a policy rule like:
	```JavaScript
	const SAFE_METHODS = new Set(['GET','HEAD','OPTIONS']);
	const SENSITIVE_ENDPOINTS = new Set([
	'/user/profile',
	'/account/details',
	]);
	const site = req.get('Sec-Fetch-Site');
	const path = req.path;
	// Block if cross-site + unsafe method OR cross-site + sensitive endpoint
	if (site === 'cross-site' && (!SAFE_METHODS.has(req.method) || SENSITIVE_ENDPOINTS.has(path))) {
	return false; // forbid this request
	}
	```
	1.3. Allow `same-origin`. Treat `same-site` as allowed only if your threat model trusts sibling subdomains; otherwise handle `same-site` conservatively (for example, require additional validation).
	```JavaScript
	const trustSameSite = false; // set true only if you trust sibling subdomains
	if (site === 'same-origin') {
	return true;
	} else if (site === 'same-site') {
	// handle same-site separately so the subcondition is clearly scoped to same-site
	if (!trustSameSite && !SAFE_METHODS.has(req.method)) {
	return false; // treat same-site as untrusted for state-changing methods
	}
	return true;
	}
	```
	1.4. Allow none for user-driven top-level navigations (bookmarks, typed URLs, explicit form submits) where appropriate.

Screenshot

[Naetiksoni08]

Hi maintainers,

I went through the issue and I understand the problem around handling cross-site requests.

From my understanding, the goal here is to start using browser-provided headers (such as Sec-Fetch-Site) so the server can understand whether a request is coming from the same origin, a same-site subdomain, or a cross-site context, and then make safer decisions based on that.

I was thinking of the following approach:

• first, inspect and validate Sec-Fetch-Site to determine whether the request is same-origin, same-site (subdomain), cross-site, or none
• handle cross-site requests more strictly, especially for non-safe HTTP methods
• treat same-site (subdomain) requests with caution as well, since subdomains can also be a potential attack surface
• explicitly handle Sec-Fetch-Site: none, which indicates user-initiated navigation (typed URL or bookmark), and apply appropriate safeguards

Before starting any implementation, I wanted to check whether this direction aligns with how you’d like this issue to be addressed.

If this approach makes sense, I’d be happy to work on implementing it. Please let me know if you have any suggestions or improvements.

Thanks!

[mackowski]

Thanks @johnbillion for reporting, do you have time to make a PR with the fix?

@Naetiksoni08 the issue here is rendering issue on the website ;)