How website attacks work — and how to defend your site

Originally published in 2013 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

The original version of this post taught readers how to attack a website's database with a few crafted inputs. That technique — SQL injection — still works against vulnerable sites today, which is exactly why this rewrite exists: to help site owners recognize, detect, and eliminate the flaws attackers exploit, described only at the level of detail defenders need.

How the classic attacks look to a defender

1. SQL injection

Attackers probe input fields (logins, search boxes, URL parameters) to see whether their input gets executed as part of a database query. What your telemetry shows: requests containing quote characters, SQL keywords, or boolean conditions in fields that should hold names or numbers; unusual error messages returned to the browser; sudden changes in query result size.

2. Authentication abuse

Attackers hammer login and password-reset flows with credential stuffing and brute force. What your telemetry shows: bursts of failed logins from many IPs or a single rotating proxy, high session-creation rates, and successful logins from impossible geographies right after a failure wave.

3. Cross-site scripting (XSS)

Attackers try to get the site to render their content in other users' browsers — stealing sessions and spreading malware. What your telemetry shows: script tags or event handlers appearing in stored user content, comments, and form submissions; CSP violation reports spiking.

Fixes that actually close these holes

Parameterized queries / prepared statements for all database access — never build queries by concatenating user input. This is the single fix that ends SQL injection.
Output encoding plus a strict Content-Security-Policy to neutralize stored and reflected XSS.
Input validation and least-privilege DB accounts so that even a successful injection can only touch what the app itself can touch.
Rate limiting, account lockout policies, and MFA on every authentication path, including password reset.
Keep frameworks, CMS, and plugins patched — known web-app CVEs are the cheapest attacker's foothold.

Detect, don't just prevent

Log web requests centrally and alert on injection signatures and abnormal input patterns.
Monitor database audit logs for queries touching unexpected tables or running at odd hours.
Run periodic authorized scans (DAST/SAST) against your own site to catch regressions before attackers do.

Authorization disclaimer

All security testing must only be done on systems you own or are explicitly authorized to assess. Probing any other website's inputs for vulnerabilities without written permission is illegal, no matter how curious you are.