What are the most common website attacks?

The most common categories are catalogued in the OWASP Top 10. They include broken access control, cryptographic failures, injection (such as SQL injection and cross-site scripting), insecure design, security misconfiguration, vulnerable and outdated components, authentication failures, and insufficient logging and monitoring. Most real-world breaches exploit one of these well-known, avoidable weaknesses rather than some novel, sophisticated technique, which is why standard defences are so effective.

How do I prevent SQL injection and cross-site scripting?

Prevent SQL injection by using parameterised queries (prepared statements) so user input is always treated as data, never as executable SQL, and by validating input. Prevent cross-site scripting by encoding output for the context it appears in, validating input, and deploying a Content Security Policy so injected scripts cannot run. The common principle is never to trust user-supplied input and never to mix untrusted data into code or markup without proper handling.

What is broken access control and how do I defend against it?

Broken access control is when users can reach data or actions they should not — for example by changing an ID in a URL to view someone else's record, or accessing an admin function without authorisation. It is consistently one of the most common serious flaws. Defend against it by enforcing least privilege, checking authorisation on the server for every request, denying by default, and never relying on hiding a link or on front-end checks that an attacker can bypass.

Do I need a web application firewall (WAF)?

A WAF is a valuable layer, not a substitute for secure code. It filters incoming traffic and blocks many common malicious requests — injection attempts, known exploit patterns, and some automated attacks — before they reach your application, and can provide virtual patching while you fix an underlying issue. For most public-facing sites, especially on platforms like WordPress, a WAF (often available through a CDN) is a sensible addition, but it should sit on top of good fundamentals, not replace them.

What is the single most important thing I can do to secure my website?

There is no single silver bullet, but keeping all your software updated is the highest-impact habit, because vulnerable and outdated components are a leading cause of breaches and the fixes already exist. Pair it with strong authentication plus multi-factor authentication on admin accounts, and tested backups. Updates close known holes, MFA stops most credential attacks, and backups mean that if something still gets through, you can recover quickly rather than catastrophically.

How to Protect Your Website from Common Attacks

The reassuring truth about website security is that most attacks are not exotic — they exploit a small set of well-known, avoidable weaknesses, and the defences are equally well established. If you secure against the common categories catalogued in the OWASP Top 10, you have closed the doors attackers actually use. This guide is a defensive, plain-English walkthrough of those common attacks and, more importantly, exactly how site owners defend against each one. It contains no exploit code — the goal is to help you harden your site, not attack anyone else's.

It ties together several other guides on this blog, including what is a Content Security Policy and how to set one and the detection side, how to tell if a website has been hacked.

The mindset: never trust input, always defend in depth

Two principles underpin almost everything that follows.

First, never trust user input. Anything that arrives from outside your server — form fields, URL parameters, headers, uploaded files, API payloads — could be crafted by an attacker. Treat it as untrusted until you have validated and properly handled it. A large share of attacks come down to a site mistaking attacker-supplied data for trusted instructions.

Second, defence in depth. No single control is perfect, so layer them: assume each layer will eventually fail and put another behind it. HTTPS, input validation, access control, patching, headers, a firewall, monitoring and backups are not alternatives — they are layers, and their value is cumulative.

With those in mind, here are the main risk categories and their defences.

Injection (including SQL injection)

The risk. Injection happens when untrusted input is interpreted as a command. The classic example is SQL injection, where input smuggled into a database query changes the query's meaning — potentially exposing or destroying data. The same idea applies to OS command injection and other interpreters.

The defence. Use parameterised queries (prepared statements) so that user input is always passed as data, never concatenated into the code of a query — this single practice eliminates the vast majority of SQL injection. Add input validation (accept only what fits an expected format), use safe ORM/database libraries, and apply least privilege to the database account so even a successful injection has limited reach. The principle: keep data and code strictly separated.

Cross-site scripting (XSS)

The risk. XSS injects malicious JavaScript that runs in your users' browsers, able to steal session tokens, harvest form input, or alter the page. It is one of the most common web vulnerabilities.

The defence. Encode output for the context it appears in (HTML, attribute, JavaScript, URL) so user-supplied data is rendered as text, not executed as code; validate input; use frameworks that auto-escape by default; and deploy a Content Security Policy so that even an injected script from an unapproved origin will not run. CSP is the strongest backstop here — see the dedicated CSP guide for how to roll one out safely.

Broken access control

The risk. Broken access control — consistently among the most common serious flaws — is when users can reach data or perform actions they should not: changing an ID in a URL to view another user's record, calling an admin endpoint without authorisation, or escalating their own privileges.

The defence. Enforce authorisation on the server, for every request, and deny by default — grant access only when a check explicitly allows it. Apply least privilege so each account and role has only the access it needs. Never rely on hiding a link or a front-end check, both of which an attacker simply bypasses. Test access control deliberately, including by trying to access other users' resources.

Security misconfiguration

The risk. Insecure defaults, unnecessary features left enabled, verbose error messages that leak internals, default credentials, exposed admin panels, and missing security headers all fall here. Misconfiguration is extremely common because it is easy to overlook.

The defence. Harden systematically: change default credentials, disable features and ports you do not use, suppress detailed error messages in production, restrict and protect admin interfaces, and set security headers (see HTTP security headers explained). Keep configuration consistent across environments so a careful staging setup is not undone by a sloppy production one.

Vulnerable and outdated components

The risk. Most sites are built on a stack of software — a CMS, themes, plugins, libraries, a server — and any of these can have known vulnerabilities that are publicly documented. Attackers scan the web for sites running outdated, vulnerable versions, because the exploit is already known and the patch already exists. This is one of the leading ways sites are breached.

The defence. Patch relentlessly. Keep your CMS, plugins, themes, dependencies and server software current; remove components you no longer use (every unused plugin is attack surface for no benefit); and track what you run so you know when something needs updating. This is unglamorous, but it is among the highest-impact things you can do.

Authentication and identity failures

The risk. Weak or reused passwords, credential-stuffing using leaked passwords, missing brute-force protection, and poor session management let attackers take over accounts — especially damaging when an admin account falls.

The defence. Require strong, unique passwords, enable multi-factor authentication (MFA) on every admin and privileged account (MFA alone stops the great majority of credential attacks), rate-limit and lock out repeated failed logins, manage sessions securely (proper expiry, secure cookies), and remove unused accounts. Combine with least-privilege roles so a single compromised login does limited damage.

Cryptographic failures and data in transit

The risk. Sensitive data exposed because it is not encrypted in transit (no HTTPS) or stored insecurely.

The defence. Use HTTPS everywhere and enforce it (see what is HTTPS and why your site needs it), keep your TLS configuration modern, and store sensitive data using appropriate, current cryptographic practices (for example, properly hashing passwords). Never roll your own cryptography.

A prioritised defence table

Risk category	Primary defence(s)
Injection / SQL injection	Parameterised queries, input validation, least-privilege DB account
Cross-site scripting (XSS)	Output encoding, input validation, Content Security Policy
Broken access control	Server-side authorisation on every request, deny by default, least privilege
Security misconfiguration	Harden defaults, disable unused features, set security headers
Vulnerable/outdated components	Patch everything, remove unused plugins, track your stack
Authentication failures	Strong passwords + MFA, rate limiting, secure sessions
Cryptographic failures	HTTPS everywhere, modern TLS, sound storage practices
Insufficient monitoring	Logging, alerting, regular review, tested backups

The cross-cutting layers

Some defences protect against many of the above at once and deserve their own mention:

HTTPS and HSTS — protect data in transit and underpin everything else.
Security headers and CSP — harden the browser's behaviour and blunt XSS and clickjacking.
A web application firewall (WAF) — filters common malicious requests before they reach your app and can provide virtual patching while you fix an underlying issue. Often available through a CDN. A useful layer, never a replacement for secure code.
Monitoring and logging — you cannot respond to what you cannot see; insufficient logging is itself an OWASP category. Log security-relevant events, alert on anomalies, and review periodically (this feeds directly into spotting a hacked site).
Backups — regular, tested, off-site backups are your safety net for when a layer fails. An untested backup is a hope, not a plan.

A prioritised hardening checklist

If you do these in order, you address the highest-impact risks first:

Enforce HTTPS everywhere and add HSTS once it is solid.
Patch everything — CMS, plugins, themes, libraries, server — and remove unused components.
Enable MFA on all admin/privileged accounts and enforce strong, unique passwords.
Lock down access control — least privilege, deny by default, server-side checks on every request.
Use parameterised queries and output encoding throughout the application.
Set security headers and roll out a Content Security Policy (in report-only mode first).
Add a WAF for an extra filtering layer, especially on common platforms.
Turn on logging and monitoring, and review for anomalies.
Back up regularly, store off-site, and test the restore.
Re-check periodically — security is a process, not a one-off, and every new plugin or service changes your attack surface.

A note on staying defensive

Everything here is about defending your own site — checking, hardening and detecting. If you want to understand attacks in more depth, OWASP publishes excellent, freely available defensive guidance (the OWASP Top 10 and its cheat sheets) aimed at builders and defenders, and Mozilla's MDN documents the browser security features you rely on. Both are reputable, vendor-neutral places to learn more without straying into offensive tooling. The aim is always the same: make your site a harder target than it was yesterday.

Go deeper

The strongest XSS defence in detail: what is a Content Security Policy and how to set one.
All the protective headers: HTTP security headers explained.
Detect a compromise: how to tell if a website has been hacked.
The encryption foundation: what is HTTPS and why your site needs it.

Want a quick read on your site's headers, HTTPS and configuration gaps? Analyse any URL with StackOptic — security, performance and SEO in one free report.