CSRF, XSS, SSRF: A Modern Web Security Primer
CSRF, XSS, and SSRF are three of the most common classes of web vulnerability. Cross site request forgery tricks an authenticated user into performing an action they did not intend. Cross site scripting injects malicious script into a page viewed by other users. Server side request forgery makes the server send a request the attacker controls. All three remain common in 2026 because the patterns that cause them are still in production code.
What you actually need to know
- CSRF, XSS, and SSRF are still in production code in 2026.
- Frameworks help. They do not eliminate the need for vigilance.
- SameSite cookies and CSRF tokens prevent CSRF.
- Output escaping and CSP prevent XSS.
- URL validation and allowlists prevent SSRF.
Vulnerability
Primary defense
Secondary defense
CSRF
SameSite cookies
CSRF tokens
XSS
Output escaping
Content Security Policy
SSRF
URL validation
Network controls
The core argument
The OWASP Top Ten has shifted over the years but CSRF, XSS, and SSRF have remained in the conversation because the patterns that produce them are still in production code. Modern frameworks have helped. React escapes output by default. Most server frameworks include CSRF protection by default. The defaults catch the common cases.
The defaults do not catch every case. dangerouslySetInnerHTML in React. Sites that disable CSRF protection on specific endpoints because the team did not understand it. Server side fetch calls that take a URL from user input. Each of these is a specific careless pattern that produces the vulnerability the framework would otherwise have prevented.
The teams that take security seriously train people on these patterns, add tooling that catches them automatically, and check for them at code review. Training, tooling, and review together are the discipline that produces secure web applications. The teams that rely on the framework defaults alone occasionally ship vulnerabilities they could have prevented.
The cost of the discipline is small. The framework already does most of the work, and the team only has to learn the patterns that break its defenses. That learning takes hours. The vulnerability, if it lands, takes hours to days of crisis to clean up.
The specific defenses
CSRF defenses. SameSite cookies set to Lax or Strict for session cookies. CSRF tokens on state changing requests. Custom headers like X-Requested-With that the browser would not send on cross site requests. SameSite alone is not enough because older browsers do not honor it. The combination is the discipline.
XSS defenses. Output escaping by default in templates. Content Security Policy header that restricts where scripts can come from. Sanitization libraries for user input that allows rich content like comments or rich text. Avoid eval, new Function, and dangerouslySetInnerHTML. When you must use them, sanitize first.
SSRF defenses. Validate every URL before fetching. Block requests to private IP ranges from user provided URLs. Use a fetch wrapper that enforces the allowlist. Disable redirects. The wrapper is the place to enforce these rules consistently.
How much does this cost
The cost of the disciplines is small. A few hours of team training. CI rules that catch the common careless patterns. Code review awareness. The combination is roughly one sprint of work to establish. The ongoing cost is the discipline.
Features the security setup must have
- SameSite cookies on sessions.
- CSRF tokens on state changing requests.
- Output escaping by default in templates.
- Content Security Policy header.
- Sanitization for user provided rich content.
- URL validation wrapper for server side fetches.
- Allowlist for outbound server requests.
- Security training for the team.
Expert opinion
The three classic vulnerabilities are still common because the patterns that cause them are still common. The frameworks have made the basic cases safe. The careless patterns remain. The teams that catch these in code review and CI ship secure web applications. The teams that rely on the framework alone occasionally ship vulnerabilities. The discipline is small and well understood. The cost of skipping it is the kind of incident you do not want.
Yashveer Singh, founder of Yashveer Labs
How this played out on a real project
A client SaaS was preparing for a SOC 2 audit. We ran a security review before the auditor arrived. The review found a CSRF vulnerability on a specific endpoint where the team had disabled CSRF protection because it was an API endpoint. We added the protection back with a proper token mechanism. The fix was an hour.
A second review found an SSRF issue. A feature that fetched the user's avatar from a URL they provided did not validate the URL. The user could provide an internal URL and trick the server into proxying it. We added a URL validation wrapper. The fix was a few hours.
A third review found an XSS issue in a rich text editor. The team had disabled the default sanitization because they wanted custom HTML in comments. We replaced the editor with one that allowed safe HTML and sanitized everything else. The fix was a day.
All three were fixed before the auditor saw them. The vulnerabilities would have been findings if discovered later. The pre audit review paid for itself.
For more on the related work, see OWASP top ten for SaaS in 2026 and insecure direct object references the bug founders underestimate.
Common mistakes teams make
- Disabling framework CSRF protection without understanding it.
- Using dangerouslySetInnerHTML or equivalent without sanitization.
- Fetching URLs from user input without validation.
- No Content Security Policy.
- SameSite cookies not set on sessions.
- No team training on the patterns.
- No CI rules that catch the careless patterns.
- Treating security as the framework's job alone.
A 30 day plan to put defenses in place
- Week one. Audit the current code for the careless patterns.
- Week two. Fix the gaps. Add SameSite cookies, CSP, URL validation.
- Week three. Add CI rules that catch the patterns.
- Week four. Train the team. Establish code review awareness.
For more on the related work, read OWASP top ten for SaaS in 2026 and server side request forgery the quiet killer in SaaS integrations. On the broader security side, building a security program from zero a twelve month plan is the natural next read.
FAQ
Frequently asked
- What is CSRF in plain terms?
- How do I prevent CSRF?
- What is XSS?
- How do I prevent XSS?
- What is SSRF?
- How do I prevent SSRF?
- Which is the most damaging?
Author
Why Yashveer Singh is the call for this work
I have spent the last four years writing software that runs in production. Three live client sites. A Roblox game with real players. Nexli, a school management system about to launch into private testing. Nyxera, a fully local AI assistant. Most people writing about this topic are summarizing other people's blog posts. I am writing from the codebase. If you want this kind of work done right, I am the person you call. Yashveer Singh, founder of Yashveer Labs.