Service · Software testing and QA

Penetration testing

Picture a polyclinic group in Ankara with a handful of branches. Patients use an online portal to book visits, check lab results and download reports. Over time several different contractors have added to it. The intention is that every patient sees their own results and nobody else's. But suppose someone changes the result ID in the browser's address bar by one digit and a stranger's blood work appears. Under KVKK, health data is a special category of personal data, and a hole like that would hit patients and the clinic hard. Access control flaws of this sort are both widespread and damaging, and automated scanners are poor at spotting them. A scanner simply does not know that patient A must never see patient B's file. A penetration test looks at your application with the owner's signed authorisation, thinks like an attacker and relies mainly on manual work. Every weakness found is documented with proof, and fixes are confirmed by testing again.

Send an enquiry See what this service covers

Signed authorisation

from the owner, before any testing

OWASP

WSTG, ASVS and MASVS

Hands-on

logic and access control flaws

Retest

confirms the fix

What the work covers in practice

Scope differs from one application to the next. These are the areas where we typically spend most time on a web application.

Agree the scope with the engineer who will do the work

Role and permission matrix

We map which records and functions each role should reach, then try every cell of that table. Boundaries between patient, doctor, receptionist and admin accounts are where leaks most often occur.

Routes to account takeover

Is there a limit on login attempts? Can an SMS one-time code be guessed or skipped? Can a password reset link be redirected to someone else's account? Does a session really end on logout?

Abusing the business rules

Altering the basket total on the client side, redeeming a single-use code again and again, grabbing a booked appointment slot: behaviour that is not a bug in the technical sense but still harms your business.

Inputs and uploads

SQL and command injection, XSS, dropping malicious files into upload fields and hand-editing request parameters.

APIs and the mobile client

Whether the API behind the mobile app authorises each request on its own, whether it throttles traffic, and whether keys or personal data sit on the device in plain text.

What faces the internet

Forgotten subdomains, admin and database consoles left open, publicly readable cloud folders and components stuck on old versions.

A report in two layers

A plain summary for management, and for developers each finding with its CVSS score, step-by-step reproduction and a suggested fix.

How we approach the job, from first call to handover

The test window, contact people and our source IP addresses are confirmed in writing beforehand, so your team knows what is a test and what is not.

Initial call

Roles in the application, sensitive data, where it is hosted and a suitable time slot.

Authorisation letter

Signed by the system owner and, where relevant, the hosting company, stating scope and dates.

Test window

Mainly manual examination with Burp Suite and similar tools. If we find something critical, we tell you at once rather than waiting for the report.

Findings and retest

An encrypted report, a video debrief with developers and verification once fixes are in.

Book the test with time to fix things, not the week of launch. A penetration test two days before go-live that turns up a critical hole forces an ugly choice: postpone the launch or go live knowing the hole is there. Leave a margin of a few weeks so findings can be fixed and retested before the date.

Frequently asked questions

Because getting into someone's system without permission is an offence under Turkish law, whatever the motive. Authorisation has to come from the real owner, and if a host or service provider runs the system, we get their approval too.

For a grey box test, one test account per role, API documentation if you have it and the addresses the application runs on. You never need to share your own passwords or real patient or customer data.

The detailed report is a roadmap for attackers and should stay within a small circle. For outside audiences we prepare a short summary listing scope, dates and the retest outcome.

At least yearly, and whenever the application changes shape: a new payment method, a new login method, a new API or a move to different infrastructure. If you fall under cybersecurity legislation or sector regulations, regular testing can be part of your risk management.

Scans quickly find known flaws and missing settings and are worth running regularly. But a scanner cannot know that one patient must not see another patient's results. Access control and business logic flaws are found only by a person who understands the application.

Neighbouring services that often go with this one

Back to the overview of this area

Service Functional testing An independent check that the software you are about to accept really follows your business rules Service Load and stress testing Measure how much traffic your platform survives well ahead of the day it matters Service Test automation Automated checks that flag a broken flow within minutes of a code change Service Usability and UX testing See with real people where your site or app loses them, and why

Let us look before attackers do

What does the application do, which roles does it have, what sensitive data does it hold and who owns the system? We will suggest a scope and schedule.

Email
office@apply.tr

Availability
Weekdays 09:00-18:00 Turkey time (GMT+3); an answer follows by the next working day

Calls
By video, over Microsoft Teams or Google Meet

I consent to Apply processing the information above to respond to this enquiry, in line with the privacy notice