Service · Software testing and QA

Penetration testing

Imagine an accountancy firm in Valencia that has just launched a portal where its two hundred clients download payslips, VAT returns and deeds. It works, it is convenient, and nobody has asked what happens if a client changes the number shown in the browser address bar. A penetration test is exactly that: a controlled attempt to get where nobody should, commissioned by the system owner and authorised by them in writing. We agree on paper which addresses and features are in scope, on which dates and at what times, and who can be reached if something goes wrong. We run no destructive tests and touch nothing outside the scope. You end up with a report that helps you fix issues, feeds your risk analysis and supports preparation for ENS or ISO 27001 audits.

Send an enquiry Jump to what is included

Authorisation

signed by the owner before we start

Scope

closed and described in the contract

Approach

hands-on, focused on business logic

Retest

of your fixes at the end

What falls within the scope of this service

We follow the OWASP methodology (the WSTG and ASVS guides), but the value lies in manual work: the most damaging flaws are logic errors that no automated scanner will find.

Pin down the details with one of our engineers

Login and sessions

Sign-in, password reset, two-factor authentication, session expiry and, if your system uses them, Cl@ve, FNMT digital certificates or Microsoft Entra ID sign-in.

Permissions between users

Whether one client can see another's data, whether a basic role reaches admin functions, whether someone who has left can still log in. On client portals and B2B platforms this is the most frequent and most serious finding.

Data tampering

SQL injection, malicious scripts in text fields, uploaded files that are not what they claim to be, prices or quantities altered in the request before it reaches the server.

APIs and mobile apps

We check whether the API enforces permissions itself or trusts whatever the app tells it, whether it rate-limits requests and whether the app stores keys or tokens unprotected on the phone.

Exposed configuration

Admin panels reachable from the internet, debug mode left on, downloadable backups, missing security headers, software versions with known vulnerabilities.

A report for two audiences

A technical section with each finding, its CVSS score, how to reproduce it and how to fix it, plus a two-page executive summary for management. Where relevant, we reference advisories from INCIBE-CERT or CCN-CERT.

How the engagement unfolds, one stage at a time

How long it takes depends on the size of the application and the scope, and the report delivery date is written into the contract. We work remotely from IP addresses shared with you beforehand, so your team can tell us apart in the logs.

Agreement and permissions

Contract, authorisation signed by the owner, detailed scope, schedule and emergency contacts. If a third party hosts the system, we get their consent as well.

Reconnaissance

We identify everything exposed: subdomains, APIs, forgotten test environments, technologies and versions.

Controlled testing

Manual work supported by tools such as Burp Suite, with no denial-of-service attacks or actions that alter real data.

Report and retest

A walkthrough for your team over video call, a remediation plan and a final check that the holes are closed.

Until the flaws are fixed, the report is the most sensitive document in the company. It explains step by step how to get in. We deliver it encrypted to the people you name and advise against forwarding it or saving it in shared folders until the final retest confirms everything is closed.

Common questions

Yes, when the system owner commissions it and there is written authorisation with scope and dates. Without that document we do nothing, even if whoever gets in touch insists they have permission. If the system belongs to a group or is hosted by a provider, the authorisation must come from whoever actually owns it.

We can work blind, as an outsider would, or with test accounts for each user role. The second option, known as grey box, is the one we recommend: for the same budget it covers far more ground and uncovers permission flaws between users.

We avoid anything destructive, but no test carries zero risk. That is why we prefer a staging environment. If production has to be tested, it happens in an agreed window, with a recent, verified backup and someone from your team on hand.

We do not issue certificates and do not promise one. You receive a report setting out scope, dates, method and findings and, after the fixes, a retest statement. That is what an auditor or a large client usually asks for during supplier vetting.

Once a year as a baseline, and always after significant changes: a new payment method, an API opened to third parties, a hosting migration or changes to login. For organisations bound by the ENS or NIS2, it fits into their regular risk management.

Other work we do in this field

Full area overview

Service Functional testing Making sure every feature does what the business actually needs Service Load and stress testing Finding the system's limit before its busiest day Service Test automation Repetitive checks that run themselves with every version Service Usability and UX testing Watching real people use your service and seeing where they get stuck

Let us put your application's security to the test

Describe the application, who owns it and whether a test environment exists. We will propose scope, schedule and an authorisation template.

Email
office@apply.es

Hours
Monday to Friday, 9:00-18:00 Spanish time (CET), answers within a working day

Meetings
Video calls via Google Meet or Teams

I agree that Apply may use my details to answer this request, as set out in the privacy policy