Service · Software testing and QA

Penetration testing

Think of a law firm in Nova Gorica running a client portal. Clients upload papers, track their cases and fetch draft agreements. The portal has been extended year after year by a series of developers. Each client is meant to see only their own files, by design at least. Now suppose a client edits the document ID in the URL, adds one, and opens another client's agreement. For a practice entrusted with confidential material, that would be a grave incident with GDPR implications as well. Broken access control is one of the most widespread and harmful categories of flaw, and automated scanners are poor at spotting it: they cannot know that client A has no business reading client B's papers. Penetration testing studies your application through an attacker's eyes, mostly by hand, with signed permission from whoever owns the system. Every weakness is recorded with proof, and once fixed it is retested so you know it is genuinely shut.

Signed permission
from the owner, up front
OWASP
WSTG, ASVS and MASVS as the basis
Hands-on
catches logic and access flaws
Verification
proves each fix works

Scope of the service

No two scopes are alike. For a typical web application these are the areas that absorb most of the effort.

Check the scope with an engineer

Access matrix

We draw up which records and actions every role may reach, then attempt each combination. The lines between client, lawyer, assistant and admin accounts are where leaks usually happen.

Taking over accounts

Is there a cap on login attempts? Can a one-time code be predicted or bypassed? Can a reset link be steered to a different account? Is the session truly invalidated on sign-out?

Bending the business logic

Changing a price in the browser, redeeming a single-use code repeatedly, booking an occupied slot: not bugs in a narrow sense, yet damaging to you.

Input and uploads

SQL and OS command injection, XSS, hostile files dropped into attachment fields and hand-edited request parameters.

APIs and mobile apps

Does the API behind the app check authorisation on each call, throttle abuse, and avoid leaving keys or personal data unencrypted on the handset?

What the internet can see

Old subdomains, admin and database consoles left open, world-readable cloud storage and components several versions behind.

Report in two layers

A non-technical summary for the board, and for developers a CVSS rating, exact reproduction steps and remediation advice per finding.

How the work runs

Test window, contacts and the IP addresses we will use are fixed in writing beforehand, so your staff can tell testing from a real incident.

01

Scoping call

Roles, sensitive data, hosting arrangements and a convenient period for testing.

02

Permission

Signed consent from the system owner and, if relevant, the host, stating scope and dates.

03

Testing period

Largely manual work in Burp Suite and similar tools. Anything critical is reported to you immediately, not saved for the write-up.

04

Results and verification

An encrypted report, a video session with your developers and a re-check after remediation.

Leave room for remediation; do not test on the eve of launch. Testing two days before release turns a critical finding into a dilemma: postpone, or ship with a known hole. Book the test so that several weeks remain for fixing and re-checking.

Your questions answered

Accessing another party's information system without authorisation can be a criminal offence, whatever the motive. The real owner of the system has to grant it. Where a host or outside contractor runs the application, we get their sign-off as well.

For grey-box work: a test login per role, API docs if they exist, and the URLs in scope. Your passwords and genuine client data are not needed.

The detailed version is effectively a burglar's plan, so keep it to a few people. For third parties we write a brief statement covering scope, dates and the retest result.

Yearly as a minimum, and after any major change such as a new payment or sign-in method, a new API or a move to new infrastructure. If you fall under NIS2 and ZInfV-1, periodic testing can form part of your risk measures.

Scanning finds known issues and weak configuration quickly and should continue. It cannot grasp that one client must never read another's documents. Access and logic flaws need a human who understands the system.

Get there before the attackers

Tell us the purpose of the application, its roles, the sensitive data it holds and who owns it. We will suggest a scope and timing.

When we work
Weekdays 9:00-17:00 CET, answers the same or next working day
Calls
Video meetings, Teams and Meet both welcome

We set essential cookies only: the ones that keep the site running and recall which town you chose. Nothing for ads and nothing that follows you around the web. Details are in our privacy and data protection notice.