Secure Development in OpenMRS: OWASP Top 10

Secure Development in OpenMRS: OWASP Top 10

Version: Based on OWASP Top 10:2025
Audience: OpenMRS contributors, module developers, and implementers
Last reviewed: Apr 9, 2026
Maintained by: NSF - OpenMRS Working Group

What is the OWASP Top 10?

The Open Worldwide Application Security Project (OWASP) is a non-profit foundation that produces freely available resources around web application security. Their Top 10 is the most widely referenced awareness document in application security: a ranked list of the ten most critical security risks facing modern web applications, updated roughly every four years based on real-world vulnerability data and community surveys.

The 2025 edition analyzed over 175,000 CVE records and reflects the evolving threat landscape, including new risks like Software Supply Chain Failures and Mishandling of Exceptional Conditions.

This is not a compliance checklist -- it is an awareness tool. The goal is to help every OpenMRS contributor recognize, understand, and avoid the most dangerous classes of vulnerability when writing code, designing features, or configuring deployments.


Why Does This Matter for OpenMRS?

OpenMRS is a mission-critical platform. It stores and processes sensitive patient health data in some of the world's most resource-constrained and high-risk environments. A security vulnerability in OpenMRS is not just a software bug -- it can directly affect patient safety, privacy, and trust in healthcare systems.

As an OpenMRS developer, you work with a stack that presents unique security considerations:

  • A modular architecture (OMODs / ESM apps) where third-party modules can introduce vulnerabilities into core deployments

  • A REST API (webservices.rest module) and FHIR layer exposing patient data over HTTP

  • A role/privilege system enforced via Spring AOP that must be correctly applied across core and module code

  • Hibernate/Liquibase at the data layer, where improper query construction can lead to injection

  • Legacy UI (Spring MVC/JSP/DWR) and O3 frontend (React microfrontends) with different security profiles

  • Deployments in diverse environments, from Docker on cloud to on-premise servers in low-bandwidth clinics, each with different configuration risks

Every contribution, whether to core, a module, the frontend, or infrastructure, is a potential security touchpoint.


The OWASP Top 10:2025 at a Glance

#

Category

OpenMRS Relevance

Priority

#

Category

OpenMRS Relevance

Priority

A01

Broken Access Control

Role/privilege enforcement, REST API, module isolation

High

A02

Security Misconfiguration

Server setup, Spring config, default credentials, module settings

High

A03

Software Supply Chain Failures

Maven dependencies, OMOD marketplace, CI/CD pipelines

High

A04

Cryptographic Failures

Password hashing, HTTPS, data at rest, session tokens

High

A05

Injection

HQL/SQL in DAOs, REST inputs, legacy JSP/DWR layer

High

A06

Insecure Design

Feature design, threat modeling, module API contracts

Medium

A07

Authentication Failures

Session management, REST Basic Auth, OAuth2 module, OpenMRS ID

High

A08

Software or Data Integrity Failures

OMOD installation, deserialization, CI/CD artifact signing

Medium

A09

Security Logging & Alerting Failures

Audit logs, access logging, alerting on suspicious activity

Medium

A10

Mishandling of Exceptional Conditions

Error handling in services, REST error responses, fail-open logic

Medium


Key Changes from OWASP 2021 to 2025

If you are familiar with the 2021 list, here is what changed:

  • A03: Software Supply Chain Failures is brand new, reflecting the rise of dependency-based attacks (e.g., Log4Shell, XZ Utils)

  • A10: Mishandling of Exceptional Conditions is brand new, covering poor error handling that leaks data or fails open

  • Security Misconfiguration moved up from #5 to #2, reflecting how prevalent it is across real-world deployments

  • Server-Side Request Forgery (SSRF), previously its own category, has been absorbed into Broken Access Control (A01)

  • Injection dropped from #3 to #5, reflecting improved framework-level protections (though it remains dangerous)


Developer Pre-PR Security Checklist

Before submitting a pull request, consider running through this quick checklist:

Access Control

  • Are all new REST endpoints protected by appropriate privilege checks?

  • Does new functionality respect OpenMRS role/privilege boundaries?

  • Are there any paths that bypass the RequiredDataAdvice or service-layer AOP checks?

Input Handling

  • Are all user inputs validated and sanitized?

  • Are HQL/SQL queries using parameterized queries (not string concatenation)?

  • Are REST responses filtered to avoid exposing internal stack traces?

Cryptography & Secrets

  • Are no plaintext passwords, API keys, or tokens committed to source?

  • Does password storage use the OpenMRS hashing mechanisms (not MD5/SHA-1)?

Dependencies

  • Have new Maven dependencies been checked for known CVEs?

  • Is the module's pom.xml pinned to a specific version (not LATEST or SNAPSHOT in production)?

Configuration

  • Are default credentials changed before deployment docs mention?

  • Are debug/verbose error modes disabled in production configurations?

Error Handling

  • Do catch blocks fail closed (deny access) rather than fail open?

  • Are error messages generic to the user but detailed in server-side logs?


OpenMRS Security Resources

Resource

Link

Resource

Link

Reporting a Security Vulnerability

OpenMRS Security 101: Policies & Vulnerability Management | 1. Receipt of Incident

OpenMRS Security Talk Category

talk.openmrs.org

Core Privilege Reference

TODO: Link

REST API Documentation

rest.openmrs.org

OWASP Top 10:2025 Official

owasp.org/Top10/2025


Contributing to This Documentation

Found something outdated, missing, or incorrect? Each sub-page can be edited directly. For significant changes or additions, especially if you have discovered a real vulnerability, please contact the OpenMRS security team before publishing details publicly.

If you have encountered a security issue in your module work and addressed it, consider adding it (in a non-exploitable form) to the relevant sub-page under "Real-World Examples in OpenMRS" to help other developers learn from it.


Sub-Pages