Security audits for web applications and online stores

We test web applications, APIs and WordPress or WooCommerce stores the way an attacker would, review the code and the server setup, and give you a report that says what to fix first. After the fixes we test again. We only work with written permission from the owner of the system.

When an audit is worth it

Security problems rarely announce themselves. An audit is usually triggered by a change: a launch, a departure, a question from a partner.

A developer has left, and you are not sure which keys and accesses left with them
The product is about to launch, and nobody has looked at it with an attacker's eyes
A partner, investor or corporate client asks for proof that the platform was tested
The store runs on dozens of plugins, and one of them just had a vulnerability published
The product is built on an old framework that nobody on the team wants to touch
You fixed the issues from a previous audit and need someone to confirm they are closed

What we check

Web application testing

Manual testing of the application and its business logic: access control, input handling, file uploads, sessions, and the flows where money or personal data change hands.

APIs and authentication

Login, password reset, tokens and JWT handling, roles and permissions. We check whether one user can reach another user’s data by changing an ID in a request.

WordPress and WooCommerce

Plugins and themes with known vulnerabilities, admin access, exposed files and configuration, and checkout logic such as prices, coupons and order status changes.

Security code review

Reading the code and its history for secrets in the repository, unsafe queries, missing checks and outdated libraries, including legacy stacks nobody has reviewed for years.

Server hardening

SSH and firewall rules, open ports, TLS, security headers, database and file permissions, backups stored apart from the server, and brute-force protection that does not lock out your own office.

Retest

After your team or ours fixes the findings, we test each one again and update the report with its status.

What we do not do

These rules are part of every agreement and are not negotiable.

We do not test any system without written permission from its owner
We do not run load or denial-of-service tests on production without a separate agreement
We do not share findings with anyone except the contacts named in the agreement
We do not keep your data or test accounts after the work is finished

A report that says what to fix first

A list of two hundred scanner warnings does not help a team decide what to do on Monday. Our report rates every finding by severity using CVSS, shows the evidence, such as the request and response that prove the problem, explains how to reproduce it and says how to fix it. The owner gets an executive summary in plain language, and the developers get a remediation plan ordered by risk and effort.

Where serious problems usually hide

Automated scanners find outdated versions. The problems that let someone take over accounts are usually elsewhere: an API that returns another customer’s order when the number in the request changes, a signing key committed to the repository years ago, an admin route that checks the login but not the role, a checkout that trusts the price sent by the browser, a backup file left in a public folder. Finding these takes a person who reads the code and tries the flows by hand, which is how we test.

Retest and hardening, so the report is not the end

An audit pays off only when the findings are closed. After the fixes we retest every finding and mark it as closed, partly fixed or still open. If you want, our developers make the fixes themselves, and our server team hardens the infrastructure: access by keys only, a firewall that exposes only what must be public, current TLS, separate database users with minimal rights and backups kept away from the server they protect.

How an audit goes

Scope and permission

We agree what is tested, from where and when, and the system owner signs a written authorisation. You provide test accounts and, for a code review, repository access.

Testing

We map the application, test it by hand and review the code and server setup within the agreed scope. Anything critical is reported to you immediately, not saved for the report.

Report

You get findings rated with CVSS, evidence, fixes, an executive summary and a remediation plan, and we walk your team through them.

Fixes

Your developers or ours work through the plan in order of risk.

Retest

We test every finding again and issue an updated report with the status of each one.

What we test and against what

Standards

Applications

Platforms and stacks

Infrastructure

Ways to work with us

Audit with retest

A fixed scope: testing, report and a retest after your team fixes the findings.

Audit and fixes

We test, fix the findings in the code and on the server, and confirm with a retest.

Regular reviews

A review before major releases or on a schedule, often combined with website or server support.

Reviews

We treat each client and his project with love.

Revol team continues to streamline the client’s development capabilities through their high-quality work and reliable support. They communicate effectively and exhibit a strong understanding of the client’s needs and business.

Tomas

CEO (Yukon, Canada)

The work from Revol, have fully met expectations and satisfied the client. Their fresh approach and ability to remain available for support have been valuable assets. Customers can bring them on for a communicative, client-oriented team to achieve their goals with.

Andrey

CEO, Stellium (USA)

Frequently asked questions

Do you need our permission in writing?

Yes, always. The owner of the system signs an authorisation that states the scope, addresses and dates. If the system runs with a hosting or cloud provider, we also follow that provider's rules for security testing.

Will testing break our live site?

We agree the limits in advance. Where possible we test on a staging copy with the same code. On production we use test accounts, avoid destructive actions and do not run load tests without a separate agreement.

How is this different from an automated vulnerability scan?

A scanner finds known versions and common misconfigurations, and we use scanners too. The findings that matter most, such as one user reading another user's data or a price changed in the browser, need a person who understands the application and tests it by hand.

What exactly do we receive?

A report with each finding rated by CVSS, the evidence, reproduction steps and the fix, an executive summary for management and a remediation plan. After the retest you get an updated version with the status of every finding.

Can you fix what you find?

Yes. Our developers can fix the code and our server team can harden the infrastructure. Some clients prefer their own team to fix and us to verify, which works just as well.

Is the retest part of the audit?

We plan it into the scope from the start, because an audit without a retest leaves you guessing whether the fixes worked. When the retest happens depends on how quickly the fixes are made.

How do you handle our data and the findings?

We work under an NDA, share findings only with the contacts named in the agreement and delete test data and accesses when the work ends. We never publish details of what we find.

Is this a certification?

No. We are not a certification body, and the report is not a compliance certificate. It can support your compliance work and shows partners who ask for proof of testing exactly what was checked and how.