When I tell people I test websites for a living, they usually ask the same thing: "So how do you actually hack a website?" They're expecting a secret. A single weapon. One magic command that opens every door. The truth is more boring and far more useful: there is no magic command. There is a methodology. A professional doesn't hack a website in one move — they move through phases, and each phase feeds the next. The entire art is in the order of operations.
In this guide, I'll walk you through that exact methodology, command by command, using example.com as the stand-in for any site you own and are authorized to test. This is the same playbook used in real engagements — reconnaissance, scanning, enumeration, exploitation, and reporting — with the tools and flags you'll actually use. By the end, you'll be able to audit your own website the way a penetration tester would, and — more importantly — understand what every finding means and how to fix it.
Before You Start: The Golden Rules of Testing Your Own Site
Three rules protect you from becoming the cautionary tale instead of the security-conscious owner:
- Only test what you own. Your domain, your subdomains, your server, your app. If you didn't register it or build it, you don't test it. The line is that simple.
- Say it in writing. Even when testing your own property, write down the scope: which domains and IPs are in, which are out, and the dates you're testing. This turns your work into an audit instead of an accident.
- Document everything. Every command and every result, saved and timestamped. If you find something, the evidence is your report. If you break something, the evidence is your repair guide. Professionals record everything, always.
Set up a working folder before touching anything:
mkdir -p ~/pentest-example && cd ~/pentest-example mkdir -p recon active webapp reports/evidence
Phase 1: Passive Reconnaissance — Learning Without Touching
Passive recon means gathering information about the target without sending a single packet to it. You're using public records: domain registration data, DNS, and search engines. This phase is safe, legal, and often the most revealing — because almost every website leaks more about itself than its owner realizes.
Start with the domain itself:
whois example.com # registrar, expiry date, nameservers dig example.com A # IPv4 address dig example.com AAAA # IPv6 address dig example.com MX # mail servers dig example.com NS # nameservers dig example.com TXT # SPF, DKIM, DMARC, verification tokens host example.com
Read the output like a detective. The WHOIS record tells you when the domain expires — an expired or expiring domain is an acquisition risk. The TXT records tell you whether email authentication is configured: a missing DMARC record means someone could spoof emails from your domain. The MX records reveal your mail provider. Every record is a clue.
Then hunt for subdomains — the most common place where forgotten, unpatched, or abandoned systems hide:
subfinder -d example.com -all amass enum -passive -d example.com
Finally, use search engines as your intelligence database (run these in a normal browser):
site:example.com site:example.com filetype:xml site:example.com inurl:search
You can also harvest any publicly exposed email addresses — useful for testing your own phishing resilience:
theHarvester -d example.com -b all
Phase 2: Active Reconnaissance — Now You're Talking to It
Active recon means sending traffic to the target and reading its responses. This is where you learn what's actually running. Start with a port scan to see what services are exposed:
# Host discovery nmap -sS -Pn -T4 example.com # Service and version detection on web ports nmap -sV -sC -Pn -p 80,443 example.com # Full port sweep nmap -p- -Pn -T4 --min-rate 2000 example.com
Reading the results: an open port 22 means SSH, a custom high port might mean a database or admin interface exposed to the internet — that's a finding. Then fingerprint the web server and look for known weaknesses:
whatweb example.com # technology stack: server, CMS, framework, cookies nikto -h https://example.com # known-vulnerability scanner curl -sI https://example.com # inspect security headers + cookies testssl.sh --full https://example.com # TLS cipher and version audit
When you run curl -sI, check the headers you actually control from your hosting panel: X-Frame-Options (clickjacking protection), X-Content-Type-Options (MIME sniffing protection), Content-Security-Policy (script injection protection), and Strict-Transport-Security (force HTTPS). A site missing these is handing out free favors to attackers.
Phase 3: Directory and File Enumeration — Hunting the Hidden
Websites always have more pages than their menus show: admin panels, backup files, configuration files, old uploads. Directory brute-forcing finds them by trying thousands of likely names against the server:
gobuster dir -u https://example.com -w /usr/share/wordlists/dirb/common.txt -t 50 gobuster dir -u https://example.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
Also check the standard files every site publishes:
curl -s https://example.com/robots.txt curl -s https://example.com/sitemap.xml
A robots.txt that lists /admin or /backup is a treasure map wrapped in a polite note — search engines respect it, attackers don't. If your own robots.txt reveals something sensitive, that's a finding. And if any subdomain from Phase 1 returns an NXDOMAIN or a parked error page while still having a DNS record, test it for subdomain takeover — an abandoned subdomain pointing at a decommissioned hosting service is one DNS change away from being someone else's phishing site under your name:
# For every subdomain found in Phase 1 dig CNAME <sub>.example.com
Phase 4: Web Application Testing — The Inputs That Lie
This is where most real vulnerabilities live: in the inputs your site accepts. Every form, every parameter, every query string is a place where the attacker's data meets your server's trust. Here's how each classic attack is tested — against your own site, of course.
Cross-Site Scripting (XSS)
XSS happens when a website echoes user input without sanitizing it, letting an attacker inject JavaScript that runs in visitors' browsers. Test every input your site reflects — search boxes are the classic example:
# First, confirm the input is reflected at all curl -s "https://example.com/search?q=test123" | grep -i test123 # Then test with classic payloads curl -s "https://example.com/search?q=<script>alert(document.cookie)</script>" curl -s "https://example.com/search?q=%22%3E%3Csvg%20onload=alert(1)%3E" curl -s "https://example.com/search?q='%22%3E%3Cimg%20src=x%20onerror=alert(document.domain)%3E"
If the payload executes, an attacker could steal session cookies, deface pages, or redirect visitors to malware. The fix is always the same: encode output, validate input, and never trust the browser. The most dangerous variant is stored XSS — where the payload is saved to the database and served to every visitor, including your admin. That one payload can silently compromise every session on the site.
SQL Injection
SQL injection lets an attacker manipulate the database queries behind a parameter. Test it first by hand, then automate:
# 1. Look for a parameter that talks to a database (e.g. /product?id=1) curl "https://example.com/product?id=1'" curl "https://example.com/product?id=1' OR '1'='1" curl "https://example.com/product?id=1' -- -" # 2. If the site reacts differently, escalate with sqlmap (your own app only!) sqlmap -u "https://example.com/product?id=1" --batch --dbs sqlmap -u "https://example.com/product?id=1" -D dbname --tables sqlmap -u "https://example.com/product?id=1" -D dbname -T users --dump
The telltale sign: an input that makes the page return an error, behave differently, or — with ' OR '1'='1 — return everything. The fix is non-negotiable: parameterized queries. Never build SQL by string concatenation.
Command Injection
If any part of your app passes user input to the operating system's shell, an attacker can inject their own commands:
# Classic test: an app that pings a host curl "https://example.com/ping?host=127.0.0.1;id" curl "https://example.com/ping?host=127.0.0.1|whoami" curl "https://example.com/ping?host=127.0.0.1`id`"
If the output of id or whoami appears in the response, the shell is exposed — and the attacker is one step from full server control. The fix: never pass user input to a shell. If you must, use a strict allowlist, not blacklists.
Broken Access Control (IDOR)
This one needs no fancy tooling — just curiosity. If a URL contains an ID, change it:
# If you see your own order at /order/1002, try: curl "https://example.com/order/1001" curl "https://example.com/order/1000"
If you can read another user's order, invoice, or profile, that's an IDOR — one of the most common and most damaging vulnerabilities in modern web apps. The fix: the server must verify authorization on every object access, not just "are you logged in?" but "are you allowed to see this record?"
Phase 5: The Platform Layer — Accounts and Configuration
Here's the uncomfortable truth professionals know: many of the most successful "hacks" never touch a line of code. They target the account layer. For any site, your real crown jewels are:
- The email account that owns everything. Whoever controls it controls password resets for the whole infrastructure.
- The domain registrar account. Whoever controls it controls the domain itself — they can redirect your entire site, intercept your mail, and lock you out forever.
- The hosting/panel account. Whoever controls it can replace every file on the server.
- Third-party integrations. Analytics scripts, chat widgets, payment links — one compromised third-party script executes code in every visitor's browser.
So test these like an attacker would:
# Audit every external script your site loads curl -s https://example.com/ | grep -oE '<script[^>]*src="[^"]*"' | sort -u
If any of those script sources is a domain you don't recognize, investigate it — and if you keep third-party scripts, add Subresource Integrity attributes (integrity="sha384-...") so a compromised CDN can't inject code into your pages. Then harden the account layer itself: two-factor authentication on the email account, the registrar account, and the hosting panel; domain transfer lock enabled; and recovery options that you actually control.
The E-Commerce Checklist: If Your Site Sells Anything
If your site handles payments, add these tests to your routine:
- Price tampering: modify a price or coupon value in the request and see if the server re-validates it. Trusting client-side totals is a one-way ticket to selling products for a cent.
- Race conditions: send two checkout requests simultaneously and see if stock or quantity limits can be bypassed.
- Payment flow: test whether order status can be altered before payment, and confirm the app never logs raw card data anywhere you control.
- IDOR on orders: the test from Phase 4 applied to transactions — changing an order number and seeing someone else's data is a critical finding.
# Parallel request test (run against your own storefront) for i in 1 2; do curl -s -X POST https://example.com/checkout -d "item=1&qty=1" & done; wait
Phase 6: Reporting and Remediation — The Part That Made You a Professional
An untested thought is just a thought, but a documented test is an audit. Save evidence for every finding:
cp homepage.html reports/evidence/ curl -sI https://example.com > reports/evidence/headers.txt
Then record each finding with its severity and fix. Here's the framework I use:
- Critical: SQL injection, command injection, authentication bypass, any way to take over the server or the database. Fix immediately, offline if necessary.
- High: IDOR, stored XSS, subdomain takeover, exposed admin panels. Fix this sprint.
- Medium: reflected XSS, missing security headers, weak TLS configuration, missing DMARC. Fix this month.
- Low: information leakage, outdated software versions, verbose error messages. Fix when convenient — but log it.
And the practical fixes for the most common findings:
- SQL injection / command injection: parameterized queries; never pass user input to a shell.
- XSS: encode all output, validate all input, add a Content-Security-Policy header.
- IDOR: server-side authorization checks on every single object access.
- Missing security headers: add them in your hosting panel or framework config — no server-level access needed for most platforms.
- Missing DMARC/SPF: add the TXT records at your registrar.
- Subdomain takeover: remove dead DNS records and decommission unused services properly.
- Weak accounts: 2FA everywhere, unique passwords, domain transfer lock.
Frequently Asked Questions
Is it legal to hack my own website?
Yes — testing systems you own is legitimate security work. The key word is ownership: if you register the domain, control the server, and administer the platform, you can test it freely. The moment you touch someone else's system without written authorization, you've crossed into criminal territory, regardless of your intentions.
Do I need special permission to scan my own site?
For your own property, no. But two caveats: if the site is hosted on shared infrastructure (like a platform or a shared server), keep the scans respectful of the platform's terms, and consider informing your hosting provider of a scheduled test. For any third-party services (payment processors, CDNs), test only what your contract allows.
What if I find a vulnerability I can't fix myself?
Isolate it first — disable the affected feature or restrict access temporarily — then document it clearly. If the platform handles the vulnerable component, submit a ticket with your evidence. If it's your own code, bring in a developer you trust, or hire a professional to verify and fix it. Never sit on a critical finding without a plan.
How often should I test my website?
Run the full passive and scanning phases monthly — they're cheap and fast. Run the deep application tests quarterly and after any major change: new features, new plugins, new third-party scripts, or a server migration. Websites don't get hacked on the day you test; they get hacked on the day after.
Can I use these commands on any website to test its security?
Only if it's yours, or you have written authorization from the owner. The commands in this guide are exactly what professionals use — and exactly what law enforcement considers unauthorized access when applied to systems you don't own. The difference between a pentester and a defendant is one signed document.
Final Thoughts: The Order Is the Weapon
Look back at what we just did: we learned about the site without touching it, mapped its services, enumerated its hidden parts, attacked its inputs, audited its account layer, and wrote down everything. No magic. No single exploit. Just a disciplined sequence where every phase made the next one easier. That is the entire difference between someone who can hack a website and someone who can only talk about it.
The beautiful part is that this skill compounds. The first time you audit your own site, you'll find misconfigurations and missing headers and maybe a real bug. The second time, you'll find fewer — because you fixed the first round. And every round after that, your site gets genuinely harder to break into, because you're the one who learned where the weak points are. That's not paranoia. That's professionalism. Test your own site the way an attacker would — before an attacker does.
