Complete website security hardening guide: XSS, CSRF, SQL injection prevention

Website security is not optional. According to Verizon's data breach report, 43% of cyber attacks target small websites — simply because small sites rarely have a dedicated security team while their attack surface is no smaller. For most site owners the real threat isn't a nation-state actor but automated scanners and batch attacks exploiting common flaws. Nail the defenses below and you'll block well over 90% of everyday threats.

OWASP Top 10 key threats

OWASP (Open Web Application Security Project) updates its top ten web application security risks about every three years. Injection, Broken Access Control, and XSS have consistently ranked near the top. This article focuses on the three that building teams encounter most often and can most easily prevent: XSS, CSRF, and SQL injection.

1. XSS (Cross-Site Scripting)

Attackers inject malicious scripts into web pages that execute in users' browsers. The most common variant is stored XSS: a user pastes a <script> into a comment, nickname, or rich-text field; the server stores it unescaped; and when other users open the page, the script runs in their browsers — stealing cookies, hijacking sessions, or serving phishing popups.

Protection:

  1. Output encoding — escape all user-supplied data before rendering (React escapes JSX by default; Vue escapes {{ }} but not v-html)
  2. Content Security Policy (CSP) — restrict resource sources; start with Report-Only mode, then enforce
  3. HttpOnly cookies — prevent script access to session cookies

Remember two principles: validate input, encode output. Any user-controlled content must be escaped before rendering; for rich text, use an allowlist filter (allowed tags and attributes) rather than a blocklist.

2. CSRF (Cross-Site Request Forgery)

Attackers trick logged-in users into executing unintended actions. A typical scenario: you post in a forum that embeds <img src="https://bank.example.com/transfer?to=hacker&amount=1000">, and the browser automatically sends your login cookie with the request. Legacy systems that perform state-changing actions via GET are especially vulnerable.

Protection:

  1. CSRF tokens — include unique tokens in forms and validate server-side; modern frameworks (Laravel, Django, Rails, Spring) ship this by default — don't disable it to save time
  2. SameSite cookie attribute — Strict blocks all cross-site cookies, Lax allows safe requests; use Lax for most sites, Strict for admin panels
  3. Validate Referer/Origin headers against an allowlist

3. SQL Injection

Attackers manipulate database queries through malicious input. The classic case: entering ' OR '1'='1 in a login box. If the server concatenates strings into queries, the attacker can bypass authentication or dump entire tables.

Protection:

  1. Parameterized queries (prepared statements) — ALWAYS use these
  2. ORM frameworks (Prisma, TypeORM, Eloquent, SQLAlchemy)
  3. Principle of least privilege — never use root for app connections; grant only the SQL operations the app needs

4. More security practices

  • Password hashing with bcrypt/argon2 (never plaintext, never MD5/SHA1 — they're rainbow-table fodder)
  • HTTPS enforcement with HSTS (Strict-Transport-Security)
  • Secure file upload handling (extension allowlist, size limits, rename files, store outside the web root, serve via a separate domain, scan for malware)
  • Regular dependency updates

A real case

An e-commerce admin once validated only the MIME type on its upload endpoint. An attacker uploaded a PHP script disguised as an image, executed it on the server, and planted a backdoor across the site. The fix: extension allowlist, file renaming (drop user-controlled filenames), storage outside the web root, and access through a controlled script on a separate domain. These flaws aren't "new technology" — they're basics done incompletely.

Security checklist

  • All user input validated and escaped
  • Parameterized queries or ORM in use
  • HTTPS enabled with HSTS
  • Security headers configured (CSP, X-Frame-Options)
  • CSRF protection or SameSite cookies
  • Passwords hashed with bcrypt/argon2
  • Correct file and directory permissions
  • Regular software/dependency updates
  • Logging and monitoring enabled
  • Data backup strategy established

16IDC Takeaway

Website security relies on defense in depth, not a single measure. Even with WAF and CDN, secure application-level coding remains an irreplaceable foundation — a WAF catches known signatures, but only code-level fixes can repair business logic flaws. Initial hardening on new servers matters too; see server initialization security, and for HTTPS and certificates see our SSL/TLS deployment guide.

Reference: OWASP Top 10 https://owasp.org/www-project-top-ten/; Verizon Data Breach Investigations Report https://www.verizon.com/business/resources/reports/dbir/