Cybersecurity

A website security test is an agreed attempt to break into your site while it is live, so you see its weak points before an attacker does. We put the site under load, try attacks through its forms and URLs, guess passwords, look for exposed admin panels and review the hosting. Unlike an automated scan, which lists possible problems, every finding in the report has been reproduced and ranked by severity.

The report lists every finding with its severity, the steps that reproduce it and what to fix first. It is yours to hand to another team without going through us. High severity means a stranger can do real harm today; medium means the harm depends on a condition that is likely; low means a safeguard is missing but the harm also depends on something unlikely. Ask the same of the whole site: who owns the code and the access.

The site may slow down or stop responding, which is why the load test runs only inside a window you approve in advance, outside your peak hours. The test is meant to find the point where the site gives up: if it does, that is the finding, not an accident, and the report says at what load it happened. Once we reach that point we stop the load; there is nothing to gain from keeping the site down.

The best time for a security test is before something important depends on the site: a launch, a busy season, a new customer login or payment method, a move to another host. It is also worth doing on a site nobody has updated since launch. A test covers the site as it was that day; repeat it after any big change. How long it takes depends on the scope; we agree it in writing, with the window, before we start.

Yes, we fix what we find if you want us to, as a separate quote, so you see that cost apart from the test. Your own team can work from the report instead. After the fixes, on request, we go back through the findings and confirm that each one is closed.

Yes. An online store that takes payments is where a security test matters most, because it holds orders, addresses and customer accounts. We test sign-up and login, the basket, coupons, forms, the admin and the return from the payment page. With card payments the number is usually entered on the payment provider's page, not in the store, so we test the path around it. Starting a store from scratch? See online store development.

Shut the attacker out and keep the evidence: from a device you trust, change the hosting, FTP, database, admin and email passwords, and delete nothing before copying it. Tell your host: it has logs and often older backups. If the site redirects visitors or shows someone else's content, take it offline. Restore from a backup made before the break-in, not necessarily the latest. Then a security test shows how they got in, and website maintenance keeps updates and backups going.