Website & Web App Penetration Testing

What’s included

Done properly, start to finish

01

A scope you can read

One page: which systems, which user roles, what’s off-limits, the test dates and who to call if we find something urgent.

02

Manual testing first

Logins, access control, injection, file uploads, business logic and APIs tested by hand. Scanners help; they don’t lead.

03

Mapped to OWASP

Coverage follows the OWASP Web Security Testing Guide, and every finding is rated with CVSS so priorities are clear.

04

Evidence, not guesses

Each finding comes with proof, steps to reproduce, the affected addresses and a concrete fix.

05

Urgent issues raised at once

If we find something critical mid-test, you hear about it the same day, not in the final report.

06

Re-test included

After fixes go in, yours or ours, we test every finding again and update the report to show it closed.

How much we know going in

Black, gray or white box

The more we can see, the more we find in the same time. Gray box suits most websites.

Black box

We start with nothing but the address, like an outside attacker would.

Gray box

We get a test account at each user level, to check what signed-in users can reach. Our default.

White box

We also review the code and configuration, which finds issues testing alone would miss.

The steps

From first message to closed

01
Scope
A call, then the written scope, dates, price and authorization.
02
Test
Manual and automated testing in the agreed window.
03
Report
Findings ranked by risk, with evidence and fixes.
04
Fix
Your developers or ours apply the fixes.
05
Re-test
Every finding checked again; the report shows it closed.

What you get at the end

Reports are written for two readers: the people who fix things, and the people who sign off.

A summary for non-technical readers: what we tested, what we found, what it means
Every finding with its severity (CVSS), evidence, steps to reproduce and a fix
A re-test report showing which findings are closed
A short letter you can share with clients, partners or insurers

An example

The kind of thing scanners miss

Logic and access-control flaws don’t have a signature. Finding them takes someone who signs in as one customer and tries to be another.

F-04 High · CVSS 7.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N

Any customer can read and delete other customers’ form submissions

Where: A custom plugin’s AJAX actions: admin-ajax.php?action=get_submission&id=1043
What we found: The action checks that you’re signed in, but not that the submission is yours. Changing the number returns anyone’s submission, and a second action deletes it.
Why it matters: Names, emails and messages from every customer were readable by any account holder. A scanner wouldn’t catch this; it needs a person who tries it.
Fix applied: Ownership and capability checks added to both actions, nonces enforced, and IDs replaced with unguessable tokens. Tested on staging, then deployed.
Re-test: Not reproducible with any test account. Closed.

Example finding, written for this page. It isn’t from a client report.

Start here

Request a security assessment

Tell us what you run and what worries you. We’ll reply with a scope, dates and a fixed price in writing, and you decide from there.

A reply from the people who’ll do the work
Scope, dates and a fixed price before anything starts
An NDA before we start, if you want one
Nothing is tested without written authorization

Urgent? Message us on WhatsApp ↗

Your name

Work email

Company or practice (optional)

Website or app address

What do you need?

Platform

How urgent is it?

Urgent: it’s happening now Within a month Planning ahead

Anything we should know? (optional)

I own these systems, or I have the owner’s permission to request security testing of them.

Please don’t include passwords, keys or full findings. We use your details only to reply. Privacy

Questions

Before you ask

Anything else: marketing@eterni.tech

How is this different from a vulnerability scan?

A scanner checks for known problems in known software. A penetration test also checks how your site behaves: whether one customer can see another’s data, whether a form can be abused, whether a flaw in the logic lets someone skip a step. Those need a person.

Can you test a site you didn’t build?

Yes. Most of what we test was built by someone else. We need written permission from the owner and, ideally, a contact at the hosting company.

Will you test the live site?

Carefully, if that’s what you want: non-destructive tests in an agreed window. Anything risky runs against a staging copy, and we never run denial-of-service tests.

Can you sign an NDA first?

Yes, before scoping if you like.

More security services

The rest of the loop

WordPress security

Audits, hardening and fixes for WordPress: plugins, users, logins, configuration and the server underneath.

Penetration testing for websites and web apps