OWASP Top 10 for
Medical & Dental Practices

Access control means "this user should only see their own data." Broken access control means that restriction isn't enforced properly. It's the number one finding in modern web app testing — present in 94% of applications tested according to OWASP data.

In a medical or dental context, the scenario is brutally straightforward. Your patient portal shows appointment history and clinical notes at a URL like https://portal.yourpractice.co.za/patient/records?id=1042. An attacker logs in as patient 1041, then simply changes that ID to 1043, 1044, 1050, 1100. If the server doesn't verify that the logged-in user actually owns record 1042 — it just returns it — every patient file in your system is exposed. This is called an Insecure Direct Object Reference (IDOR), and it is shockingly common.

I have found IDOR vulnerabilities in South African practice management portals where changing a single integer in a URL exposed the full clinical history, identity documents, and medical aid details of a completely different patient. No hacking tools required. Just a browser and curiosity.

The POPIA angle: Under POPIA, you are the Responsible Party for every patient record you hold. An IDOR vulnerability that exposes patient data is a security compromise. You are legally obligated to report it to the Information Regulator within 72 hours of becoming aware of it, notify affected patients, and demonstrate that you had reasonable security measures in place. "We didn't know about it" is not a defence — a pentester would have found it in five minutes.

Previously called "Sensitive Data Exposure," this category covers all the ways that data is inadequately protected in transit or at rest — weak encryption, no encryption, deprecated algorithms, or improper key management. For healthcare, where the data is about as sensitive as it gets, getting this wrong is catastrophic.

The most common finding in practice portals? Passwords stored as MD5 hashes. MD5 is not a password hashing function — it's a checksum. It's fast to compute, which is terrible for password storage, and there are precomputed lookup tables (rainbow tables) for billions of common passwords. If an attacker dumps your user database through a SQL injection (see A03), MD5 password hashes are cracked in minutes using tools like Hashcat on a modern GPU.

Also common: web apps that transmit patient data over HTTP instead of HTTPS — or that have HTTPS but accept insecure HTTP too without redirecting. On an open network (coffee shop, your own waiting room WiFi), a man-in-the-middle attacker intercepts the plaintext and reads everything in real time.

SQL injection has been on the OWASP list since its inception. It should be effectively extinct by now. It isn't. SQL injection is still found in production healthcare web apps, and when it is present in a medical practice portal, it means the attacker can dump the entire patient database in one command.

The attack works when user-supplied input — a name, a date, an ID number in a search field — is concatenated directly into a SQL query without sanitisation. The attacker injects SQL syntax into that input, changing the logic of the query itself. Against a practice portal with a patient search field, this can mean: authenticate without a password, extract every patient record, read files from the server, or in some configurations execute operating system commands.

XSS (Cross-Site Scripting) also falls in this category. An attacker injects malicious JavaScript into a field your practice app displays to other users — a patient name, an appointment note, a referral comment. When a receptionist or doctor opens that record, the script executes in their browser, stealing their session cookie and giving the attacker full access to their authenticated session. From the server's perspective, the attacker is the doctor.

This is the one that can't be patched. Insecure design means the security flaw is architectural — it was baked into the design of the application before a single line of code was written. You can patch a missing input validation check. You cannot patch a fundamentally broken trust model.

Classic example for practices: an online appointment booking system that sends a confirmation email with a "cancel appointment" link. The link is https://book.practice.co.za/cancel?appt=8842. No authentication. No token. Just the appointment ID. Any person who guesses or enumerates that ID can cancel any patient's appointment — including cancelling every appointment in your schedule for the next month. Or, more sinisterly, cancelling specific patients' oncology follow-ups or post-surgical check-ins.

Another insecure design pattern common in local practice management systems: the "forgot password" flow uses a predictable reset token — based on the patient's ID number and the timestamp, for example. An attacker who can guess or obtain a patient's ID number can generate a valid reset token themselves and take over the account without ever receiving the email.

The most democratised vulnerability on the list. You don't need a developer to introduce it — anyone who deploys software can misconfigure it. And in a small medical practice where the IT was "set up by a guy" years ago and nobody has touched it since, security misconfiguration is almost guaranteed.

The scenarios I encounter most often: cloud-hosted practice management software with the admin panel exposed on the public internet at /admin with default credentials (admin/admin or admin/password). Web servers with directory listing enabled — visit a folder URL and the server helpfully lists every file inside it, including database backups. Error messages in production that display full stack traces with database connection strings, file paths, and framework versions — a roadmap for the next attack.

A .env file left in a public web directory is a single file that hands the attacker your database password, your email credentials, your API keys, and sometimes your cloud storage access. It happens constantly. I have found them on South African medical web apps. The file is often left there by a developer during setup and simply forgotten.

Modern web applications aren't written from scratch — they're assembled from components: frameworks, libraries, plugins, CMSs, third-party integrations. Every component has its own vulnerability history. Running an outdated version of any component means every known vulnerability in that version is available to an attacker who can look it up on a CVE database in 30 seconds.

The classic South African healthcare web app scenario: a practice website or portal built on WordPress with outdated plugins. WordPress itself is fine when maintained. But "contact form by practice admin," "appointment booking plugin v2.1 (2019)," and "PDF attachment handler v1.3" — all unpatched for three years — each carries known exploits. The WPScan tool enumerates every installed plugin and theme, identifies versions, and cross-references against a vulnerability database. It takes about ninety seconds.

This covers every failure in the authentication and session management layer — weak passwords allowed, no rate limiting on login attempts, insecure "remember me" tokens, sessions that don't expire, and session IDs exposed in URLs. For a practice portal, authentication is the front door. If it's broken, everything inside is accessible.

The most immediately dangerous issue here is credential stuffing. Your receptionist's login for the practice portal is [email protected] / Welcome1! — the same password she uses for her personal Gmail, her Takealot account, and three other services. Two of those services have been breached; her credentials are in the RockYou2024 compilation. An attacker runs an automated credential stuffing tool against your portal's login endpoint with a list of known-breached email/password pairs. No brute force. No guessing. Known working credentials, tested against your system at 500 attempts per minute because there's no rate limiting and no MFA.

This category covers assumptions about software updates, CI/CD pipelines, and serialised data — all without verifying integrity. The most famous real-world example is the SolarWinds supply chain attack, where attackers compromised a software vendor's build process and pushed malicious updates to thousands of organisations. Every one of those organisations automatically trusted and installed the update because it came from a trusted source.

For a medical practice, the most relevant scenario is insecure deserialisation in practice management APIs. Your practice management system might transmit session data or user preferences as a serialised object in a cookie or API request. If the server deserialises that data without validating it first, an attacker can craft a malicious serialised object that, when deserialised, executes arbitrary code on the server. It's an arcane attack, but the impact is remote code execution — the highest possible severity.

More practically: if your practice uses a third-party billing integration or pathology lab API that pulls a JavaScript library from an external CDN without a Subresource Integrity (SRI) hash, and that CDN is compromised, malicious JavaScript runs in every staff member's browser who opens the billing page. Skimming patient card details. Exfiltrating data. In real time.

This one is subtle. It doesn't let attackers in — but it's what allows them to stay in undetected. The global average dwell time for an attacker in a network is over 200 days. That's more than six months between initial compromise and detection. In a practice with no logging and no monitoring, that number could be indefinitely longer — or forever.

What this means practically: the IDOR attack in A01 enumerated 500 patient records. No alert was raised. The failed login attempts from credential stuffing in A07 — 3,000 attempts in twenty minutes from a Romanian IP — generated no alert. The attacker who finally authenticated with a stolen credential and has been browsing patient files for three weeks? No audit trail, no anomaly detection, nothing.

Under POPIA Section 22, you must notify the Information Regulator and affected data subjects "as soon as reasonably possible" after becoming aware of a compromise. If you have no logs, you never become aware. You also cannot fulfil your notification obligation, demonstrate the scope of the breach, or prove what data was and was not accessed. In a regulatory investigation, that absence of evidence becomes evidence of negligence.

SSRF earned its place on the 2021 list after being weaponised in some of the most significant breaches of recent years — including the Capital One AWS breach in 2019. It's less well known to non-security practitioners, but it's particularly dangerous in cloud-hosted healthcare applications.

The attack works like this: your practice's patient portal has a feature that fetches an external URL — perhaps to display a referral PDF from a pathology lab, or to pull a profile photo from a URL, or to preview a link a patient submits. The attacker supplies not an external URL, but an internal one: http://169.254.169.254/latest/meta-data/. On AWS, that address is the Instance Metadata Service — it returns the server's IAM credentials, which can be used to access your entire AWS account, including any S3 buckets holding patient backups.