CSRF is often seen as low impact today because modern browsers have protections like SameSite cookies, Origin checks, and CSRF tokens. These make it much harder to exploit in real applications. But CSRF can still be dangerous in old systems or badly configured apps.

CSRF + local network means taht in some misconfigured cases, a CSRF bug might trigger requests to internal services that the browser can reach. But it does NOT normally give full control over internal APIs, routers, or local host services in modern browsers because of browser security rules like Private Network Access and same-origin policy.

CSRF vulnerability concept

Cross-Site Request Forgery (CSRF) is a bug where an attacker tricks a logged-in user’s browser into sending a request without the user meaning to do it.

This works because the server trusts the browser and automatically accepts cookies or session data.

So if a user is logged in, and they visit a malicious page, the browser might send a request like:

<img src="https://target.com/api/delete-account?confirm=yes">

The server thinks the user really sent the request, even though they didn’t click anything.

CSRF only works when protections like CSRF tokens, SameSite cookies, or Origin checks are missing or broken.

CSRF protection types

Common protections are:

  • Anti-CSRF tokens – random values added to requests

  • SameSite cookies – controls when cookies are sent

  • Referer checks – checks where request comes from

  • Custom headers like X-Requested-With (not very strong alone)
    The first one (tokens) is the main protection. If it’s missing or predictable, CSRF can happen. The others only help when used correctly together.

CSRF via GET requests

Some old or bad systems use GET requests for actions that should change data.

GET /api/change-email?email[email protected]
Cookie: session=admin123

If SameSite is set to Lax, some GET requests from a link click may still send cookies.

<a href="http://target.com/api/admin/add?user=attacker">Click me</a>
window.open("http://target.com/api/admin/add?user=attacker");

this only works if the site is already insecure (no CSRF tokens, bad design).

CSRF via missing Referer

Some servers try to protect themselves by checking Referer only. If that check is weak or missing, it may fail in some cases.

<meta name="referrer" content="no-referrer">

or

<a href="https://target.com/admin/add" rel="noreferrer">Attack</a>

good systems use Origin checks + CSRF tokens, not just Referer.

CSRF via Open Redirect

Open redirect is when a website sends users to another site based on a URL parameter.

example.com/redirect?url=attacker.com

This can be used in phishing or attack chains, but it does NOT directly bypass CSRF protection.

It only becomes useful if a system is already badly designed or incorrectly trusts redirects.

Local network reconnaissance (CSRF limits)

CSRF is blind. You can send requests, but you cannot read responses because of browser security rules. Modern browsers also restrict access to private networks, such as:

  • 10.0.0.0/8

  • 172.16.0.0/12

  • 192.168.0.0/16

  • 127.0.0.0/8 (loopback)

This is enforced by mechanisms like Private Network Access.

Final summary

CSRF is still a real issue, but modern browsers block or reduce most of its impact. Most bypass techniques only work on old or misconfigured systems. Today, CSRF risk depends more on how the application is built than on the vulnerability alone.