Website Penetration Testing: What It Is and When You Need It

The best way to protect a system from an intruder is to look at it through an intruder's eyes. That is exactly the idea behind a penetration test: a security specialist gets permission to attack your website, app or network and hunts for weaknesses before someone else finds them.

For many businesses, penetration testing sounds like something only banks and tech giants need. In reality, almost any company with a website, forms, a customer portal, an online shop or a CRM integration holds data that attackers care about: customer details, orders, and access to ad accounts and payments.

In this guide we cover:

• what a penetration test is and how it differs from a vulnerability scan;
• why your business needs one and what gets tested on a business website;
• the main types of tests and who performs them;
• how a penetration test runs, step by step;
• the tools testers use;
• what European regulation expects, and how to prepare a Webflow, WordPress or Wix site for a test.

What is a penetration test (pentest)?

A penetration test, or pentest for short, is a security assessment that simulates a real attack on a system. The tester uses the same techniques as attackers, but does so with the owner's consent, within an agreed scope and without causing damage.

The goal is not just to find a single "hole", but to understand what an attacker could actually achieve. Can they read customer data, take over an admin account, change a price in the shopping cart or inject code into the site? At the end of the engagement you receive a report listing every finding, its severity and how to fix it.

Tests are carried out by security professionals known as penetration testers, pentesters or ethical ("white hat") hackers. They usually have a background in server and network administration, a deep understanding of web protocols and web applications, and the ability to write code.

Penetration test vs vulnerability scan

The two terms are often confused, but the difference matters:

• A vulnerability scan is automated. Software crawls your website or server and compares what it finds against a database of known weaknesses: outdated plugin versions, misconfigurations, expired SSL certificates. Scans are fast and relatively cheap, but they produce false positives and do not understand your business logic.
• A penetration test is human work. The tester uses automated tools too, but also tries to chain several small weaknesses into one attack, explores scenarios no scanner knows about and confirms that each finding can really be exploited.

The right approach combines both: regular automated scanning, plus a manual penetration test before launch, after major changes and at regular intervals.

Why your business needs a penetration test

A security flaw can cost a business far more than money. A customer data leak damages trust, can trigger mandatory notifications to regulators and sometimes leads to legal claims. A compromised website can be turned into a malware distribution tool, and Google may flag it as dangerous and drop it from search results.

Some damage has nothing to do with hackers in the classic sense. Flaws in your site's logic can let ordinary customers take advantage of them: redeem a coupon several times, change a quantity or price in a request sent to the server, or view another customer's order by changing a number in the URL. Bugs like these do not show up in regular testing because they do not "break" the site. A penetration test is designed to uncover exactly them.

What gets tested on a business website

On most business websites, a penetration test focuses on these areas:

• Forms and input fields: SQL injection, XSS and malicious file uploads through contact and sign-up forms;
• Login and permissions: weak passwords, unlimited login attempts, two-factor authentication, and what a regular user can view or change;
• Payments and orders: tampering with prices, quantities and discounts, and skipping steps in the checkout flow;
• APIs and integrations: connections to your CRM, payment providers and automation tools, exposed API keys and unauthenticated webhooks;
• Server and domain configuration: SSL certificates, security headers, files and folders left publicly accessible, forgotten subdomains;
• Third-party components: plugins, themes, JavaScript libraries and external scripts.

We covered the most common threats themselves, from phishing to ransomware, in our guide to information security threats for businesses. A penetration test is how you find out whether your defences against them actually work.

Types of penetration tests

Tests differ by how much the tester knows in advance, the vantage point they attack from and their area of specialisation.

White box

The tester gets full information about the system: network layout, source code, server configuration and test accounts at every permission level. Your team knows the test is happening and cooperates.

• Pros: an in-depth review of every layer of the system, including code and internal logic, and the discovery of weaknesses that are hard to spot from outside.
• Cons: requires full cooperation, takes longer and costs more.

Black box

The tester starts from zero, just like a real attacker. They gather information from open sources, map the website and look for entry points with no help from the inside.

• Pros: simulates a real-world attack and shows what an outsider can see.
• Cons: part of the time goes into collecting information you could simply have handed over, and weaknesses that require knowledge of the system may be missed.

Gray box

The tester gets partial information, for example a regular user account and a general description of the system. This is the most common option for websites and apps of small and mid-sized businesses, because it balances depth against budget.

• Pros: a realistic test from several permission levels at a reasonable cost.
• Cons: you need to define exactly what information the tester receives, otherwise it is hard to compare one test with the next.

Red team and blue team

Large organisations split the work between two teams. The red team attacks: it simulates sustained attacks and tests not only the technology but also how the organisation responds. The blue team defends: it monitors, detects anomalies, responds to incidents and strengthens defences. When the two work together, sharing findings and learning from each other, this is sometimes called a purple team.

A small business does not need teams like these. An external security provider who runs periodic tests, plus a development partner who fixes the findings and keeps the system up to date, is enough.

External and internal

An external test checks what can be done from the internet: your website, domain, servers and any services exposed to the world. An internal test assumes the attacker is already inside, for example through an employee's infected laptop or a leaked password, and checks how far they can get across your network.

There are other specialisations as well: web and mobile application testing, wireless network testing, social engineering (such as a controlled phishing campaign aimed at staff) and physical testing, where the tester tries to get into the office posing as a courier or a job candidate.

How a penetration test works, step by step

The process varies with the size of the project, but most tests follow the same stages.

1. Scope and written authorisation

Before anything starts, you define exactly what is being tested: which domains, which systems, at what times, and which actions are off-limits (for example, load attacks on a live site). The business gives written authorisation. Without it, attempting to break into a system is a criminal offence in most countries, even with good intentions.

It is also important to check what your providers' terms of service allow. Cloud platforms and managed website builders define what you may and may not test on their infrastructure. For example, you test your own website, not the platform's underlying infrastructure.

2. Reconnaissance and mapping

The tester maps everything that is exposed: subdomains, servers, technologies, software versions, employee email addresses and public documents. Findings often turn up at this stage already, such as a forgotten staging environment or a backup file left publicly accessible.

3. Scanning and vulnerability discovery

At this stage automated scanners run, and the tester manually checks the sensitive areas: forms, login, permissions, APIs and payment flows.

4. Controlled exploitation

The tester tries to exploit the weaknesses they found, to prove they are real and to understand their impact. This is done carefully: no data is deleted, the site is not taken down and no personal data is kept beyond what is needed as proof.

5. Report and recommendations

A good report is written for two audiences: an executive summary in plain language and technical detail for developers. Every finding gets a severity rating (usually based on the CVSS scale), a description, evidence and remediation guidance.

6. Remediation and retest

Once your team has fixed the findings, the tester verifies that the fixes work and that no new weaknesses were introduced along the way. Without a retest, you cannot be sure the problem is really closed.

Tools penetration testers use

You do not need to master these tools as a business owner, but knowing them helps you read reports and ask your provider the right questions.

Vulnerability scanners: OpenVAS and Nessus

OpenVAS, now developed by Greenbone, is an open-source vulnerability scanner. It checks servers, routers, firewalls and network services, looks for outdated components, default passwords and missing updates, and produces a report with recommendations. Nessus from Tenable is the widely used commercial alternative. Similar tools include Qualys and Nexpose.

Web application testing: Burp Suite and ZAP

Burp Suite is the main working tool for most web application testers. It sits between the browser and the server, lets the tester view and modify every request, and detects vulnerabilities such as XSS and SQL injection. ZAP is an open-source alternative that also works well for regular automated scans. For WordPress sites there is also WPScan, which checks core, plugin and theme versions against a database of known vulnerabilities.

Network mapping and traffic analysis: Nmap and Wireshark

Nmap maps which hosts and services are open on a network. Wireshark analyses network traffic and shows what data is being transmitted and how. With it you can discover, for example, information sent without encryption.

Exploitation frameworks: Metasploit

Metasploit Framework lets the tester check whether a known vulnerability can actually be exploited on a specific system. It saves a lot of time, but precisely because it is so powerful, it is only used within the agreed scope.

Password testing: Hydra and Hashcat

Tools such as Hydra and Hashcat test how easy it is to guess or crack passwords. When they fail, it is a sign that your password policy, login attempt limits and two-factor authentication are doing their job.

Code analysis: SonarQube and Semgrep

Static code analysis tools scan source code without running it and flag dangerous patterns: queries open to injection, passwords hard-coded into the code, libraries with known vulnerabilities. SonarQube and Semgrep are especially popular, and it is worth wiring them into your development pipeline so they run on every change.

Penetration testing and regulation in Europe

In the EU there is no general rule that every business must run a penetration test, but several regulations come very close to it. This is a general overview, not legal advice:

• GDPR requires anyone processing personal data to apply security measures appropriate to the risk, including a process for regularly testing and evaluating whether those measures work. A penetration test is one of the most common ways to show you are doing that.
• NIS2, the EU cybersecurity directive, applies to medium-sized and large organisations in essential and important sectors, and to many of their suppliers. It requires cybersecurity risk-management measures and ways to assess how effective they are.
• DORA sets digital resilience rules for financial entities and their critical ICT providers, including regular security testing and, for the most significant players, threat-led penetration testing.
• PCI DSS, the card industry's security standard, requires penetration testing from businesses that process or store card details themselves. A website that hands payment off to a secure hosted payment page from an external provider significantly reduces its obligations.
• Large clients and tenders increasingly ask suppliers for a recent penetration test report, especially in healthcare, finance and insurance.

If a breach affects personal data, GDPR generally requires you to notify your data protection authority within 72 hours of becoming aware of it. To find out exactly which obligations apply to your business, talk to a legal adviser or an information security consultant. This guide does not replace that advice.

Webflow, WordPress and Wix: what to test on each platform

The platform your website is built on has a big effect on what is worth testing and who is responsible for each part.

WordPress

On WordPress, the business is responsible for almost every layer: the server, the core, the plugins and the theme. That is why it is the platform where penetration tests tend to find the most issues. Testers pay special attention to outdated or abandoned plugins, the admin login page, user roles, the REST API and XML-RPC if it is not in use. If your site runs on WordPress, ongoing maintenance is part of your security. You can find more in our WordPress website guide.

Webflow and Wix

On managed platforms such as Webflow and Wix, the provider takes care of the servers, updates and SSL certificates, and you cannot, and are not allowed to, test the infrastructure itself. What remains your responsibility: custom code (Custom Code and Velo), third-party scripts, forms and where they send data, APIs and webhooks connected to the site, and the access rights your staff and contractors have to the account.

Integrations and automations

For many businesses the weak spot is not the website itself but what is connected to it: scenarios in Make, Zapier or n8n, API tokens stored in insecure places, and webhooks that accept any request without checking who sent it. When you define the scope of a test, include these too. For an explanation of how access between systems works, see our guide what is OAuth.

Common penetration testing mistakes businesses make

An automated scan instead of a real test

An automated scanner report is a good start, but it is not a penetration test. It does not check business logic, permissions between users or chains of several weaknesses.

Testing a live site without a backup or coordination

Even a careful test can create test records in your CRM, send emails to customers or put load on the server. Before the test, take a backup, tell your team and, if possible, test on a staging environment identical to the live site.

A report left in a drawer

A test without fixes is not worth much. Decide who owns each finding, set a deadline for fixing it and schedule the retest. QA checks after every fix help make sure nothing else broke. We explained how to plan them in our website QA testing guide.

A one-off test

Systems change all the time: plugins get updated, new forms and integrations are added, vendors change. A test done two years ago says little about where you stand today. The usual recommendation is a test once a year, plus another one after every significant change.

A scope that is too narrow

Many businesses test only the main website and forget about subdomains, the staging environment, the app and the integrations. An attacker will look for exactly the place nobody tested.

How RJL Studio helps keep your website secure

We are not a penetration testing firm, but we build and maintain the websites, integrations and automations that penetration tests examine. On our projects we:

• build sites on WordPress and Webflow with a minimum of plugins and scripts, role-based permissions and two-factor authentication;
• configure forms, webhooks and API keys so data is not exposed on its way to your CRM and automation tools;
• prepare your site for a test: a staging environment, backups, a map of every connected system and a list of access rights;
• fix the findings from the report and run QA and regression testing before the tester comes back for the retest;
• support the site with ongoing maintenance: updates, monitoring and backups.

Got a penetration test report and not sure where to start, or want to get your site ready for a test? Get in touch and we will come back to you with a clear plan of action.

Frequently asked questions

Does a small business need a penetration test?

Not every small business needs a full test, but almost every business should check its security. If you have a customer portal, an online shop, medical or financial data, or large clients who require it, a penetration test is a sensible investment. For a simple brochure website, updates, automated scanning and two-factor authentication are usually enough.

How often should you run a penetration test?

The common recommendation is once a year, plus after any significant change: launching a new website, migrating to another platform, adding a customer portal or a payment system. Automated scans can and should run far more often.

How long does a website penetration test take?

It depends on the scope. A brochure site with a few forms usually takes a few days, while an application with user roles, payments and APIs can take two weeks or more. On top of that comes time for fixes and the retest.

Can a penetration test take my website down?

A professional test is planned so that it causes no damage, but there is always a small risk. That is why you agree in advance which actions are off-limits, take a backup, coordinate the timing and, where possible, test on a staging environment.

How is a penetration test different from a bug bounty?

In a penetration test, one provider tests the system within a set time frame and scope and delivers a structured report. In a bug bounty programme, many researchers look for vulnerabilities over a long period and are paid only for verified findings. Most businesses start with a penetration test and later add a simple vulnerability disclosure policy, for example a security.txt file on the website.