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.restmodule) and FHIR layer exposing patient data over HTTPA 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 |
|---|---|---|---|
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
RequiredDataAdviceor 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.xmlpinned to a specific version (notLATESTorSNAPSHOTin 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 |
|---|---|
Reporting a Security Vulnerability | OpenMRS Security 101: Policies & Vulnerability Management | 1. Receipt of Incident |
OpenMRS Security Talk Category | |
Core Privilege Reference | TODO: Link |
REST API Documentation | |
OWASP Top 10:2025 Official |
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
- A01: Broken Access Control
- A02: Security Misconfiguration
- A03: Software Supply Chain Failures
- A04: Cryptographic Failures
- A05: Injection
- A06: Insecure Design
- A07: Authentication Failures
- A08: Software or Data Integrity Failures
- A09: Security Logging and Alerting Failures
- A10: Mishandling of Exceptional Conditions