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.
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.
No two scopes are alike. For a typical web application these are the areas that absorb most of the effort.
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.
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?
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.
SQL and OS command injection, XSS, hostile files dropped into attachment fields and hand-edited request parameters.
Does the API behind the app check authorisation on each call, throttle abuse, and avoid leaving keys or personal data unencrypted on the handset?
Old subdomains, admin and database consoles left open, world-readable cloud storage and components several versions behind.
A non-technical summary for the board, and for developers a CVSS rating, exact reproduction steps and remediation advice per finding.
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.
Roles, sensitive data, hosting arrangements and a convenient period for testing.
Signed consent from the system owner and, if relevant, the host, stating scope and dates.
Largely manual work in Burp Suite and similar tools. Anything critical is reported to you immediately, not saved for the write-up.
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.
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.
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.
Enquiry received
An engineer will write back no later than the following working day. Faults that leave your staff unable to work are always looked at first.
No town by that name here. Check the letters, or settle for the nearest larger place. Our engineers work only over the internet, so Kočevje and Koper get precisely the same treatment.