15 Most Common Website Hacking Techniques (and What Stops Each One)

Last updated: August 2026. Written by Josh Hutcheson, OnlineCourseing editor. See our review methodology.

THE SHORT VERSION

If you administer a website, the useful question is not “how many ways can a site be hacked?” — the answer is effectively unlimited — but “which handful of things actually account for most real compromises, and what stops each of them?” This guide answers that second question.

It is written for people learning defensive security and web application security: developers who own a site, sysadmins who inherited one, and students working toward a security role. Every technique below is described at the level a defender needs to recognize it and shut it down. None of it is written as instructions for attacking a system you do not own — see the section on authorization before you practice any of it.

First, a disambiguation: two different things share this name

Search for “web hacking techniques” and you will get two completely different kinds of result, which is worth knowing before you read further.

The first is PortSwigger’s “Top 10 Web Hacking Techniques”, an annual research award. Every year the security community nominates and votes on the most innovative new web security research published that year — novel request smuggling variants, new classes of parser confusion, and so on. It is excellent, and it is genuinely cutting-edge, but it is a survey of new research rather than a list of what is hitting ordinary websites. If that is what you came for, go to PortSwigger’s research index directly.

The second — this article — is the list of attacks that actually compromise ordinary websites. These are mostly not new. Several are decades old. They persist because they keep working.

The three things an attacker can target

Almost every article on this topic presents one flat list mixing SQL injection, phishing and DDoS together. That is a genuine problem, because those three are not the same kind of event and they do not share a defense. Patching your code does nothing about a phished password. Training your staff does nothing about an unauthenticated file upload.

So the fifteen techniques below are grouped by target:

That last row matters more than it looks. A denial-of-service attack is routinely listed as a “hacking technique”, but it does not compromise anything — it makes a site unavailable. Treating the two as one category is how people end up buying a DDoS mitigation service and leaving an unauthenticated admin endpoint wide open.

Part 1: Attacks against the application (1–9)

These are the ones the OWASP Top 10 covers. OWASP is a non-profit foundation, and its Top 10 is the closest thing web security has to a consensus standard. The current release is the OWASP Top 10:2025, which replaced the 2021 edition; each technique below carries its 2025 category so you can see how it maps.

1. Broken access control (OWASP A01:2025)

The single most common category of serious web vulnerability, and the one most missing from articles like this one. Broken access control means the application checks who you are but not what you are allowed to touch. The classic form is an insecure direct object reference: you are logged in as customer 1041, you change /invoice?id=1041 to 1042, and you get someone else’s invoice. No exploit, no tooling — the permission check simply was not written.

What stops it: deny-by-default authorization enforced server-side on every request, not in the UI. If a control is only hidden in the interface, it is not a control.

2. SQL injection (A05:2025 Injection)

The attacker supplies input that the application concatenates straight into a database query, changing what that query does. It has been well understood since the late 1990s and it is still found regularly, usually in older code or in a corner of an application nobody revisited.

What stops it: parameterized queries (prepared statements) everywhere, without exception. Input validation and web application firewalls are useful defense in depth, but parameterization is what actually removes the class of bug.

3. Cross-site scripting (XSS) (A05:2025 Injection)

The attacker gets their JavaScript to run in another user’s browser in the context of your site. Stored XSS persists in your database (a comment, a profile field) and fires for every visitor who views it; reflected XSS travels in a crafted link. Because the script runs as your site, it can act as the victim.

What stops it: context-aware output encoding, a strict Content Security Policy, and treating every piece of user-supplied content as untrusted at render time rather than at input time.

4. Cross-site request forgery (CSRF)

The victim is already authenticated to your site. A page they visit elsewhere silently causes their browser to submit a request — change email, transfer funds — and their session cookie rides along automatically. The application cannot tell the difference between that and a deliberate click. OWASP maps CSRF under broken access control: its A01:2025 page names CWE-352: Cross-Site Request Forgery among that category’s notable weaknesses.

What stops it: anti-CSRF tokens on every state-changing request, plus the SameSite cookie attribute, which removes most of the attack surface on its own.

5. Security misconfiguration (A02:2025)

Nothing is exploited here in the traditional sense. Directory listing is on, a default admin account was never changed, verbose errors leak stack traces and database names, an S3 bucket is public, or a staging environment is exposed with production data in it. OWASP ranks this second because it is both extremely common and extremely cheap to attack.

What stops it: hardened, repeatable deployment configuration rather than hand-tuned servers, plus periodic review of what your site actually exposes to an unauthenticated visitor.

6. Outdated components and vulnerable plugins (A03:2025 Software Supply Chain Failures)

If you run a content management system, this is statistically the most likely way your site gets compromised — and older versions of this very article omitted it entirely. A vulnerability is disclosed in a plugin, a proof-of-concept is published within days, and automated scanners begin sweeping the internet for unpatched installs. Nobody targets you; you are simply found.

OWASP renamed and promoted this category for 2025 — it is now Software Supply Chain Failures, which broadens it beyond “outdated components” to include the build pipeline and the packages you pull in.

What stops it: knowing your dependency inventory, patching promptly, and removing plugins you no longer use. An unused, deactivated plugin still sitting on disk is still code on your server.

7. Malicious file upload and web shells

An upload feature accepts a file it should not, and the attacker lands a script inside your web root that they can then call from a browser. That script is a web shell — a persistent, interactive foothold. It is a favourite because it survives password resets.

What stops it: validating file type by content rather than extension, storing uploads outside the web root, serving them from a separate domain, and never executing anything in the upload directory.

8. Server-side request forgery (SSRF) (A01:2025)

The attacker persuades your server to make a request on their behalf — often to an internal address they cannot reach themselves, such as a cloud metadata endpoint or an internal admin service. Your server is trusted on that network; they are not. So they borrow it.

Worth noting if you learned the 2021 list: OWASP’s A01:2025 page names CWE-918: Server-Side Request Forgery among broken access control’s notable weaknesses, so SSRF now sits inside that category rather than standing alone.

What stops it: allowlisting the destinations your server may call, blocking internal address ranges at egress, and requiring authentication on internal services rather than assuming the network boundary protects them.

9. Clickjacking (A02:2025 Security Misconfiguration)

Your page is loaded in an invisible frame on the attacker’s site, overlaid with their own interface. The victim thinks they are clicking a button on that page; they are actually clicking one on yours, with their session active.

What stops it: a single response header. Content-Security-Policy: frame-ancestors (or the older X-Frame-Options) tells the browser who may frame you. This is a configuration omission, not a code flaw, which is why it sits under misconfiguration.

Part 2: Attacks against the people (10–13)

These bypass your application entirely. No vulnerability is exploited, because the attacker arrives holding valid credentials. This is why “our code passed a pentest” and “our site is secure” are different claims.

10. Phishing and social engineering

A message that impersonates something trusted — your host, your registrar, a colleague, a password reset — and collects a credential or an authentication code. Social engineering is the wider family: pretexting a support agent into a password reset, or simply calling and asking. It works because it targets judgement rather than software.

What stops it: phishing-resistant multi-factor authentication (hardware keys or passkeys rather than SMS codes), a verification path for credential requests that does not depend on the message itself, and treating anyone with publishing access as a target.

11. Credential stuffing (A07:2025 Authentication Failures)

Distinct from brute force, and more effective. The attacker takes username and password pairs already exposed in someone else’s breach and replays them against your login. They are not guessing — they are betting on password reuse, and that bet pays often enough to be worth automating at scale.

What stops it: multi-factor authentication above all, plus checking new passwords against known-breached password lists and rate-limiting by account as well as by IP address.

12. Brute force and password spraying (A07:2025)

Classic brute force tries many passwords against one account and is easily throttled. Password spraying inverts it — one common password tried against many accounts — specifically to stay under per-account lockout thresholds. Spraying is the version that still works on real sites.

What stops it: MFA, rate limiting measured across accounts rather than per account, and removing or renaming predictable default usernames.

13. Session hijacking and cookie theft (A07:2025)

Rather than steal the password, steal the session that the password already created. Session identifiers get captured through XSS, through insecure transport, or from a shared machine, and a stolen session often sidesteps MFA because the authentication already happened.

What stops it: HttpOnly, Secure and SameSite cookie flags, HTTPS everywhere with HSTS, rotating the session identifier on privilege change, and giving users a way to revoke active sessions.

See the cyber security courses we rate →

Part 3: Attacks against availability (14–15)

These do not compromise your site. They take it away from you — which is a serious problem, but a different one, with a different budget and a different owner.

14. Distributed denial of service (DDoS)

Overwhelming traffic from many sources, exhausting bandwidth, connections or application resources until legitimate visitors cannot get through. Nothing is stolen and nothing is modified. It is occasionally used as cover or as leverage for extortion.

What stops it: absorbing it upstream. A CDN or scrubbing provider in front of your origin, with the origin’s real address kept out of public DNS. This is genuinely one of the cases where the defense is a service you buy rather than code you write.

15. DNS hijacking and spoofing

Your site is untouched; the directory pointing at it is changed. If an attacker compromises your registrar account or DNS provider, they can point your domain wherever they like — and because they now control the domain, they can obtain a valid certificate for it too. Visitors reach an attacker’s server over a connection their browser calls secure.

What stops it: treating the registrar account as critical infrastructure — MFA on it, registrar lock enabled, and monitoring for changes to your own DNS records and issued certificates.

Before you practice any of this: authorization is the whole ballgame

Everything above is defensive knowledge, and reading it carries no risk. Running it against a system does. The line is not what you do, it is whether you had permission to do it, and that line is drawn in law rather than in etiquette.

In the United States, unauthorized access to a computer is governed by the Computer Fraud and Abuse Act; in the United Kingdom, by the Computer Misuse Act 1990. Most other jurisdictions have an equivalent. The tests they apply turn on authorization, not on intent or on how much damage resulted — which means “I was only looking” and “I was trying to help” are not defenses.

Professional testing is therefore paperwork before it is technical. A legitimate engagement has a written scope naming exactly which hosts and applications are in it, a defined testing window, a named authorizing party with the standing to grant it, and an agreed contact for when something breaks. If you cannot point to that document, you do not have permission — and a bug bounty program’s published policy is that document for the assets it names, and only for those.

To practice legally and without any of this ambiguity, use environments built for it: deliberately vulnerable applications you host yourself such as OWASP Juice Shop or DVWA, or hosted labs like PortSwigger’s Web Security Academy, TryHackMe and Hack The Box. We cover the legal boundary in more depth in is ethical hacking legal, and the difference between the two roles in hacking vs ethical hacking.

What actually reduces your risk, in order

Most guides on this topic are published by companies selling website security products, and they tend to arrive at the conclusion that you should buy a website security product. We sell nothing in this category, so here is the honest ordering — the first four items cost nothing but attention.

1. Turn on multi-factor authentication for every account that can publish, deploy or change DNS. This single change defeats most of Part 2.
2. Patch, and remove what you do not use. Dependencies, plugins, themes, and any staging environment you forgot about.
3. Set the headers and cookie flags. Content Security Policy with frame-ancestors, HSTS, and HttpOnly, Secure and SameSite on session cookies.
4. Enforce authorization server-side on every request. This is the fix for the number one risk and it cannot be bought.
5. Take real backups and test restoring one. An untested backup is a belief, not a control.
6. Then consider a WAF, a CDN with DDoS absorption, and monitoring. These are genuinely useful — they are just not a substitute for the five above.

If you want to go further into the tooling and methodology behind testing these, our guides to web pentesting tools and the web pentesting checklist cover the practitioner side, and network security threats covers what sits below the application layer.

Where to learn this properly

Reading a list like this is enough to recognize these attacks. It is not enough to find them, and it is nowhere near enough to be paid for finding them. That gap is closed by structured coursework plus a lot of lab time.

Our two starting points, both chosen on merit rather than on what pays us: the best ethical hacking courses covers the offensive-testing path from beginner through certification, and the best cyber security courses is the broader defensive route if your job is protecting a site rather than testing one. If you specifically want the web application layer covered above, PortSwigger’s Web Security Academy is free, written by the people who make Burp Suite, and is the single best resource in this niche — we earn nothing from saying so.

Compare ethical hacking courses →

Frequently asked questions

What is the most common website hacking technique?

For sites built on a content management system, the most common route to compromise is an unpatched vulnerability in an outdated plugin, theme or component — category A03 in the OWASP Top 10:2025. These attacks are automated and untargeted: scanners sweep for known-vulnerable versions and exploit whatever they find. Among flaws in custom application code, broken access control (A01) is the most common serious category.

Is DDoS a hacking technique?

Not in the sense of compromising a site. A distributed denial-of-service attack makes a website unavailable by exhausting its resources; it does not give the attacker access to data or code. It is a serious availability problem with an entirely different defense — upstream absorption via a CDN or scrubbing service — which is why this guide separates it from the compromise techniques.

What is the difference between brute force and credential stuffing?

Brute force guesses many passwords against one account. Credential stuffing does not guess at all: it replays username and password pairs already leaked in other services’ breaches, betting on password reuse. Credential stuffing is far more effective, which is why multi-factor authentication matters more than password complexity rules.

Does the OWASP Top 10 cover phishing?

No. The OWASP Top 10 covers risks in web applications — code, configuration and dependencies. Phishing and social engineering target people rather than software, so they fall outside its scope. That is precisely why this guide groups techniques by target: a list that mixes them implies one defense covers both, and it does not.

Is it legal to test these techniques on a website?

Only on systems you own or have written permission to test. Unauthorized access is a criminal offence under the Computer Fraud and Abuse Act in the United States and the Computer Misuse Act 1990 in the United Kingdom, and those laws turn on authorization rather than intent or harm caused. Use deliberately vulnerable practice applications such as OWASP Juice Shop or DVWA, or hosted labs like PortSwigger’s Web Security Academy, TryHackMe and Hack The Box.

What is the current version of the OWASP Top 10?

The OWASP Top 10:2025, which superseded the 2021 edition. Its categories are Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures, and Mishandling of Exceptional Conditions.

Related guides

• Best ethical hacking courses — the offensive-testing learning path
• Best cyber security courses — the defensive route
• Web pentesting tools — what practitioners actually use
• Web pentesting checklist — the methodology
• Password hacking techniques — Part 2 above, in depth
• Network security threats — below the application layer
• Is ethical hacking legal? — the authorization question in full
• Hacking vs ethical hacking — where the line sits
• Hacking terms — the 78-term glossary, grouped by attack stage