We find the vulnerabilities in your app before anyone exploits them
Manual penetration testing of web apps, APIs and external infrastructure. We reproduce every finding, show its business impact and retest the fix.
When you need a pentest now
Two matches on this list mean the test belongs in your plan.
- You are launching a new product or a major update
- You have added a new API or an integration with an external service
- You are moving into enterprise accounts and independent testing is being required of you
- It has been a long time — or never — since an external contractor tested you
- You have been through an infrastructure migration or changed hosting
- A partner, client or regulator asks for security validation
- You want to check not whether protection exists, but whether someone could actually get around it
- You have an in-house security team and need an independent view of its work
What we attack
In plain words. The exact list is fixed in the scope before we start.
Web application
Pages, forms, file uploads, handling of user input.
API
The channels your product uses to exchange data with other systems — including the ones everyone has forgotten about.
Authentication
Login, password recovery, sessions, tokens, multi-factor authentication.
Roles and access rights
Whether a user can reach data and actions that do not belong to them.
Business logic
Scenarios formally allowed by the system but open to abuse.
External services
Integrations, automatic notifications between services, third-party components and their configuration.
Configurations
Server settings, headers, access, unnecessary exposed services.
Typical vulnerability classes
Attempts to reach other people's data, substitute page content or bypass checks. Technically — injections, XSS, SSRF, IDOR and related classes.
Why a scanner is not enough
Yes, scanners are useful: they cover the known issues fast and save time. But they do not answer the main question: can this be used against you.
What a scanner sees
Known patterns, outdated versions, typical configuration mistakes. That is a useful baseline — and we collect it too.
What manual work adds
Business logic, abuse of access rights, chains of several small issues and the context of your specific product.
- A scanner does not know what "someone else's account" or "the wrong order status" means in your product
- It will not combine three individually unremarkable findings into one working attack path
- It will not tell a real problem from expected behaviour
- It will not check whether you can step outside your own role
Six stages, no surprises
At every stage you know what is happening and what comes next.
Boundaries
We agree what exactly we test: domains, applications, APIs, environments. We also record what is out of scope.
Authorisation
We obtain written authorisation to test within the agreed boundaries. Without it, active testing does not begin.
Testing
Manual testing from an attacker's position. Automated tools are supporting only. We report critical findings immediately, without waiting for the report.
Report
The report: what was found, how to reproduce it, how critical it is and what it means for the business.
Fixes
Your team makes the fixes. We stay in touch and answer questions on every finding.
Retest
We re-check what was fixed and record exactly what has been closed.
No testing without authorisation
Active testing is carried out only within the agreed boundaries and only after written authorisation.
Risky techniques are either excluded or moved to a test environment. The goal is to find a problem, not to create one.
A report your team can act on the next day
Every finding with reproduction steps, business impact and the order of fixes.
Confirmed findings
Not "potentially possible", but what we actually reproduced — with reproduction steps.
Priorities
What to close today and what to schedule. Without a 200-item list of equal weight.
Business impact
What exactly an attacker gains from exploitation: data, money, access, downtime.
Technical description for the team
Enough specifics for developers to fix it without extra guesswork.
Retest
After the fixes we check again and record the result.
Final walkthrough
We go through the results on a call: what is closed, what remains, what to look at next.
Products we test
Multi-tenant products
Tenant isolation, role permissions, APIs that grew faster than the documentation.
Money and payment flows
Payment logic, transaction limits, access to financial data.
Orders and payments
Admin panels, cart and discounts, payment system integrations, customer data.
Sensitive patient data
Booking forms, staff access, storage of medical records.
Two sides of a deal
Trust between seller and buyer, moderation, abuse of the logic.
Irreversible operations
Access, keys, integrations, system behaviour in edge-case scenarios.
The founder leads every project and answers for the result
A pentest never goes on a conveyor belt: I lead the project from planning to the final debrief and answer for the result.
I lead a cybersecurity team. Since 2019 I have run 170+ penetration tests for 80+ companies. I have worked on the security of many Ukrainian banks and payment systems, as well as government bodies and law enforcement. The founder runs the project, and nothing is handed to outside contractors.
I test systems the same way a real attacker does — from the outside, with no hints, with no access from within.
Frequently asked questions
Other Veiltrack security services
When another format is the better choice
A pentest goes deep into one application. A broader or different task? Here are the formats for it.
Vulnerability Assessment
When you need to test not one application but the whole external perimeter for known technical issues.
Veiltrack Security Program
When besides the application you need to test the perimeter, the team and the access — within one agreed set of boundaries.
Book a 30-minute review call
30 minutes: we tell you what to test, at what scope and in what time. No sales deck, no pressure.