## Why Every Developer Needs to Know This You just shipped a new web app. The UI looks great, the API responds fast, your tests pass. You push to production and go to sleep. Somewhere, an automated scanner is already probing your login form. Web attacks aren't exotic. They don't require nation-state budgets or Hollywood-style hacking rigs. Most of the techniques used to compromise real websites today were documented *decades* ago — and they still work because developers keep making the same mistakes. This guide walks you through the five most common attack vectors targeting websites: **SQL Injection**, **Cross-Site Scripting (XSS)**, **Cross-Site Request Forgery (CSRF)**, **Brute Force**, and **Phishing**. For each one, you'll learn how it works, see a realistic example, and get concrete defenses you can apply today. No prior security knowledge required. ## 1. SQL Injection (SQLi) ### What It Is SQL Injection is one of the oldest and most devastating web vulnerabilities. It occurs when user-supplied input is embedded directly into a database query without proper sanitization — allowing an attacker to *rewrite* the query itself. The attacker isn't guessing your password. They're rewriting the rules of what your login check even *means*. ### How It Works Imagine a login form that checks credentials like this on the server: ```sql SELECT * FROM users WHERE username = 'alice' AND password = 'hunter2'; ``` This looks fine. But what if the username field receives this input instead? ``` ' OR '1'='1 ``` The resulting query becomes: ```sql SELECT * FROM users WHERE username = '' OR '1'='1' AND password = 'anything'; ``` Since `'1'='1'` is always true, this query returns the first row in the database — often the admin account — without ever checking a real password. ### Real-World Impact SQL Injection attacks have been responsible for some of the largest data breaches in history: - **Heartland Payment Systems (2008)**: 130 million credit card numbers stolen via SQLi - **Sony Pictures (2011)**: 1 million user accounts exposed - **TalkTalk (2015)**: 157,000 customer records leaked, £400K fine ### Vulnerable Code Example ```javascript // ❌ NEVER DO THIS — Node.js + MySQL const query = `SELECT * FROM users WHERE username = '${req.body.username}'`; db.query(query, callback); ``` Any string the user types becomes part of the SQL query. This is the root of the vulnerability. ### How to Defend Against It **Use parameterized queries (prepared statements).** This is the single most effective defense. ```javascript // ✅ Safe — parameterized query const query = "SELECT * FROM users WHERE username = ?"; db.query(query, [req.body.username], callback); ``` With parameterized queries, user input is *never* interpreted as SQL syntax. It's always treated as a literal value. Additional defenses: - **Use an ORM** (Sequelize, Prisma, SQLAlchemy) — they parameterize by default - **Principle of least privilege**: The database user your app connects with should only have SELECT/INSERT/UPDATE on the tables it needs — never DROP or CREATE - **Input validation**: Reject inputs that don't match expected patterns (e.g., usernames should match `/^[a-zA-Z0-9_]{3,20}$/`) - **Web Application Firewall (WAF)**: As a secondary layer, not a primary defense > 💡 **Quick test**: Run [sqlmap](https://sqlmap.org/) against your own app in a staging environment. If it finds anything, fix it before someone else does. ## 2. Cross-Site Scripting (XSS) ### What It Is Cross-Site Scripting (XSS) occurs when an attacker injects malicious JavaScript into a web page that is then executed in other users' browsers. Unlike SQL Injection, which targets your database, XSS targets *your users*. The browser has no way to know that the script came from an attacker rather than from you. It executes it with full trust. ### The Three Types of XSS | Type | How it works | Persistence | |---|---|---| | **Stored XSS** | Malicious script saved in the database and served to all users | Persistent | | **Reflected XSS** | Script embedded in a URL parameter, reflected back in the response | Per-request | | **DOM-based XSS** | Script injected via client-side JavaScript that reads from the URL | Client-side only | ### How It Works: Stored XSS Example Imagine a comment section that saves and displays user comments. A user submits this as their comment: ```html Great article! ``` If the server stores this verbatim and the frontend renders it as raw HTML, every user who visits that page has their session cookie silently sent to `evil.com`. The attacker can then use that cookie to impersonate them — without ever knowing their password. ### What an Attacker Can Do with XSS - **Session hijacking**: Steal authentication cookies - **Credential harvesting**: Overlay a fake login form on the real page - **Keylogging**: Capture everything the user types - **Crypto mining**: Run mining scripts in the victim's browser - **Redirects and drive-by downloads**: Send users to malware sites ### Vulnerable Code Example ```jsx // ❌ React — dangerouslySetInnerHTML with user content function Comment({ text }) { return

; } ``` ```javascript // ❌ Vanilla JS — direct innerHTML assignment document.getElementById('comment').innerHTML = userInput; ``` ### How to Defend Against It **Escape output by default.** Every modern framework does this automatically when used correctly. ```jsx // ✅ React — safe by default (JSX escapes automatically) function Comment({ text }) { return

{text}

; } ``` ```javascript // ✅ Vanilla JS — use textContent, not innerHTML document.getElementById('comment').textContent = userInput; ``` Additional defenses: - **Content Security Policy (CSP)**: A response header that tells browsers which scripts are allowed to run. Even if an XSS payload is injected, CSP can prevent it from executing. ```http Content-Security-Policy: default-src 'self'; script-src 'self' ``` - **HttpOnly cookies**: Prevents JavaScript from reading session cookies at all, breaking the most common XSS payloads ```http Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict ``` - **Sanitize HTML when you need it**: If you genuinely need to accept and render HTML (a rich text editor, for example), use a battle-tested sanitizer like [DOMPurify](https://github.com/cure53/DOMPurify) — never write your own > ⚠️ **React developers**: JSX is safe by default, but `dangerouslySetInnerHTML` bypasses all protections. Treat it like `eval()` — avoid it unless you have a compelling reason and are sanitizing the input. ## 3. Cross-Site Request Forgery (CSRF) ### What It Is CSRF (pronounced "sea-surf") tricks a logged-in user into unknowingly sending a request to a website where they're authenticated. The website receives a valid request with real credentials — and has no way to know the user didn't intend to send it. Where XSS exploits the user's trust in a website, CSRF exploits the website's trust in the user's browser. ### How It Works Suppose a banking app processes fund transfers via a POST request: ```http POST /transfer Cookie: session=abc123 amount=1000&to_account=555-USER ``` An attacker creates a malicious webpage with this hidden form: ```html ``` When a logged-in bank customer visits `evil.com/trap.html` — even just by clicking a link in an email — their browser automatically sends the transfer request *with their valid session cookie*. The bank sees a legitimate authenticated request. The user's money is gone. They never saw a form. They never clicked submit. ### How to Defend Against It **CSRF tokens** are the standard defense. The server generates a unique, unpredictable token for each session and embeds it in every form. The server rejects any request that doesn't include the correct token — which the attacker's page can never know. ```html ``` ```javascript // Server validates the token on every state-changing request app.post('/transfer', csrfProtection, (req, res) => { // If _csrf token doesn't match, the middleware rejects the request }); ``` Additional defenses: - **SameSite cookies**: The most modern and elegant defense. Tells browsers not to send cookies on cross-origin requests. ```http Set-Cookie: session=abc123; SameSite=Strict; Secure; HttpOnly ``` `SameSite=Strict` means the cookie is *never* sent from a third-party page. `SameSite=Lax` (the browser default in modern browsers) allows it for top-level navigations but not for form submissions or XHR. - **Verify the `Origin` header**: For API endpoints, check that the `Origin` or `Referer` header matches your expected domain - **Require re-authentication for sensitive actions**: High-stakes operations (password change, fund transfer) should require the user to re-enter their password > 💡 Modern browsers now default to `SameSite=Lax`, which prevents the most common CSRF attack pattern. But you shouldn't rely on browser behavior alone — implement CSRF tokens for any state-changing operation. ## 4. Brute Force Attacks ### What It Is Brute force is the least sophisticated attack on this list — and one of the most effective. The attacker simply tries thousands or millions of username/password combinations until one works. No code injection. No clever exploits. Just relentless automated guessing. Modern brute force tools can test hundreds of requests per second against an unprotected login endpoint. ### Varieties of Brute Force | Variant | Strategy | |---|---| | **Pure brute force** | Try every possible combination (aaaa, aaab, aaac...) | | **Dictionary attack** | Try words from a wordlist (`password`, `123456`, `qwerty`) | | **Credential stuffing** | Use username/password pairs leaked from *other* breaches | | **Password spraying** | Try one common password against *many* accounts (avoids lockouts) | Credential stuffing is particularly dangerous. After large data breaches, billions of username/password pairs are available on the dark web. Since people reuse passwords across sites, attackers feed these lists into automated tools and quietly compromise accounts at scale. ### What a Brute Force Script Looks Like ```python # Simplified illustration — do not use for malicious purposes import requests passwords = ["123456", "password", "qwerty", "admin", "letmein"] for pwd in passwords: response = requests.post("https://target.com/login", data={ "username": "admin", "password": pwd }) if "Welcome" in response.text: print(f"Found: {pwd}") break ``` Without any rate limiting, this can test thousands of passwords per minute. ### How to Defend Against It **Rate limiting** is your first line of defense. Limit how many login attempts a single IP (or account) can make within a time window. ```javascript // Express.js with express-rate-limit import rateLimit from 'express-rate-limit'; const loginLimiter = rateLimit({ windowMs: 15 * 60 * 1000, // 15 minutes max: 10, // 10 attempts per window message: 'Too many login attempts. Please try again later.', }); app.post('/login', loginLimiter, handleLogin); ``` Additional defenses: - **Account lockout**: Temporarily lock accounts after N failed attempts (balance security vs. denial-of-service risk) - **CAPTCHA**: Add friction after failed attempts — even a simple checkbox CAPTCHA breaks most automated tools - **Multi-Factor Authentication (MFA)**: Even if the attacker guesses the correct password, they can't log in without the second factor. MFA is the single most effective control against credential-based attacks. - **Password hashing with bcrypt/Argon2**: If your database is ever breached, slow hashing algorithms make offline cracking computationally infeasible ```javascript // ✅ Hash passwords with bcrypt before storing import bcrypt from 'bcrypt'; const SALT_ROUNDS = 12; const hashed = await bcrypt.hash(plainTextPassword, SALT_ROUNDS); // ✅ Verify on login const match = await bcrypt.compare(inputPassword, storedHash); ``` - **Breach detection**: Services like [HaveIBeenPwned's API](https://haveibeenpwned.com/API/v3) let you check if a user's password appears in known breach databases at registration time > 🔒 **The single biggest win**: Enforce MFA on admin accounts. If brute force succeeds against an admin, the damage is catastrophic. MFA makes that scenario nearly impossible. ## 5. Phishing ### What It Is Phishing is a social engineering attack — it doesn't exploit a vulnerability in your code. It exploits a vulnerability in human psychology. An attacker creates a convincing impersonation of a trusted entity (your bank, your company's IT department, GitHub, Google) and tricks a target into voluntarily handing over credentials, clicking a malicious link, or performing an action that benefits the attacker. Phishing remains the #1 initial access vector in enterprise breaches. Technical defenses can be bypassed, but a well-crafted phishing email bypasses them entirely by going *around* the system through the human. ### Anatomy of a Phishing Attack A typical phishing campaign has three components: **1. The lure** — An email (or SMS, or DM) designed to create urgency or fear: ``` From: security@app1e.com Subject: ⚠️ Unusual sign-in detected — verify your account immediately We detected a sign-in attempt from an unfamiliar device in São Paulo, Brazil. If this wasn't you, click below to secure your account: [Verify My Account Now →] ``` Notice: `app1e.com` — not `apple.com`. The domain uses the number `1` in place of the letter `l`. Most users won't notice under time pressure. **2. The fake site** — A pixel-perfect clone of the legitimate service, hosted on a lookalike domain. The victim enters their credentials, which are captured by the attacker. They're then redirected to the real site with a "session expired" message, so they assume nothing unusual happened. **3. Credential use** — The attacker logs into the real service with the stolen credentials, often within minutes, before the victim realizes what happened. ### Spear Phishing: The Targeted Variant Generic phishing casts a wide net. **Spear phishing** is targeted. The attacker researches their victim on LinkedIn, GitHub, or company websites before crafting a message that feels *completely legitimate*: ``` From: carlos.mendes@yourcompany-hr.com Subject: Updated benefits enrollment — action required by Friday Hi Sarah, As discussed in the all-hands last Thursday, benefits enrollment closes Friday. Please use the new portal: [https://yourcompany-benefits-2024.com/enroll] — Carlos, HR ``` The attacker knows the victim's name, their company, a recent internal meeting, and the HR contact's name. The link leads to a fake portal that harvests login credentials. ### How to Defend Against It Phishing defenses operate at multiple levels: technical, organizational, and individual. **Technical controls:** - **DMARC, DKIM, and SPF**: Email authentication protocols that prevent attackers from spoofing your domain in emails they send ```dns ; SPF record — specifies which mail servers are authorized to send for your domain v=spf1 include:_spf.google.com ~all ; DMARC record — tells receiving servers what to do with unauthenticated mail _dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com" ``` - **Hardware security keys (FIDO2/WebAuthn)**: Phishing-resistant MFA. Even if an attacker captures a username and password, they cannot authenticate without the physical key — and the key is bound to the legitimate origin, so it won't respond to a fake site - **Password managers**: They autofill credentials only on the exact registered domain. A password manager won't fill in credentials on `app1e.com` — it doesn't match `apple.com` **Organizational controls:** - **Security awareness training**: Regular, realistic phishing simulations help employees develop the habit of scrutinizing unexpected emails - **Verified callback procedures**: Establish a policy that any request involving credentials, wire transfers, or sensitive data must be verified via a separate, known-good channel (a phone call, Slack DM) — not by replying to the email - **Incident reporting culture**: Make it easy and blameless for employees to report suspected phishing. The faster suspicious messages are flagged, the faster they can be blocked company-wide > 🎯 **The real defense**: Hardware security keys (YubiKey, Google Titan) make phishing attacks against accounts *technically impossible*, even if the user clicks the link and enters their credentials. For high-privilege accounts, this is the gold standard. ## The Attacker's Perspective: How These Attacks Chain Together Real-world attacks rarely use just one technique. They chain them: ``` 1. Phishing email → employee clicks link ↓ 2. Credential capture → attacker logs into internal app ↓ 3. Brute force → attacker tries admin account with common passwords ↓ 4. Admin access → attacker finds SQL query in a poorly secured admin panel ↓ 5. SQL Injection → attacker dumps the user database ↓ 6. Stored XSS payload inserted → all logged-in users get their sessions hijacked ``` This is why security is a *system* property, not a feature. A single weak link is enough. ## Your Security Checklist Use this as a quick reference when building or auditing a web application: ### Against SQL Injection - [ ] All database queries use parameterized statements or an ORM - [ ] Database user has minimum necessary privileges - [ ] Input validation rejects obviously malformed values ### Against XSS - [ ] User content is escaped on output (not input) - [ ] `innerHTML` and `dangerouslySetInnerHTML` are avoided or sanitized - [ ] Content Security Policy header is configured - [ ] Session cookies have `HttpOnly` flag ### Against CSRF - [ ] CSRF tokens on all state-changing forms - [ ] `SameSite=Strict` or `SameSite=Lax` on session cookies - [ ] `Origin`/`Referer` header validation on sensitive API endpoints ### Against Brute Force - [ ] Rate limiting on login and password reset endpoints - [ ] Account lockout or exponential backoff after failed attempts - [ ] Passwords hashed with bcrypt or Argon2 (not MD5 or SHA-1) - [ ] MFA available (and required for admin accounts) ### Against Phishing - [ ] DMARC, DKIM, and SPF configured for your domain - [ ] Security keys (FIDO2) offered as an MFA option - [ ] Password manager recommended to users - [ ] Security awareness training for team members ## Conclusion Web security can feel overwhelming — a vast, ever-shifting landscape of threats, CVEs, and attack techniques. But most real-world attacks exploit a small number of well-understood, well-documented vulnerabilities. SQL Injection is 25 years old. XSS has been in the OWASP Top 10 since the list was created. Phishing works because human psychology doesn't change. You don't need to know everything. You need to understand the fundamentals well enough that you don't make the obvious mistakes — and you need the habits (parameterized queries, output escaping, MFA, rate limiting) to become automatic. Security isn't something you bolt on after the product ships. It's a craft you develop alongside your code. Start with the checklist. Fix the obvious issues. Then keep learning. ## Further Reading - [OWASP Top 10](https://owasp.org/www-project-top-ten/) — The canonical list of web application security risks - [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/) — Deep-dive testing methodology - [PortSwigger Web Security Academy](https://portswigger.net/web-security) — Free, hands-on labs for every attack type covered here - [HaveIBeenPwned](https://haveibeenpwned.com/) — Check if credentials have been exposed in known breaches - [Burp Suite Community Edition](https://portswigger.net/burp/communitydownload) — The standard tool for web security testing - [NIST Password Guidelines (SP 800-63B)](https://pages.nist.gov/800-63-3/sp800-63b.html) — Evidence-based recommendations for authentication *This article is intended for educational purposes — for developers building more secure applications and security beginners learning how attacks work. Understanding attack techniques is the foundation of building effective defenses.*

Articles tagged “Phishing”

Beginner Guide to Cybersecurity: How Hackers Actually Attack Websites