OWASP Top 10 alignment
This page was created by Wikiadmin on 2026-07-29. Last edited by Wikiadmin on 2026-07-29.
You can use this page to assess how documented MDriven controls relate to the OWASP Top 10 when you design, deploy, and review a MDriven application.
Scope
This is an alignment guide, not a statement of OWASP compliance. Your application security depends on the rules in your model, the authentication and authorization configuration, and the way you deploy and operate MDrivenServer.
For example, defining a ViewModel that shows only a user's own orders reduces the information available to that user, but you must still define the authorization rules and configure the server correctly.
OWASP Top 10 alignment
| OWASP Top 10 risk area | Documented MDriven control or guidance | What you should do |
|---|---|---|
| A01: Broken Access Control | MDriven Turnkey access control lets a ViewModel define the slice of data shown to an authenticated and authorized user. The ViewModel reduction happens on the server, and the access-control rules are defined declaratively in the model with static verification. | Define authorization rules for each use case and make the ViewModel expose only the required data. For example, a customer-order ViewModel should expose the current customer's orders, not all orders. Review AccessGroups, InterestGroups and ViewModel-Enable when controlling whether users can perform actions that affect persistent data. |
| A02: Cryptographic Failures | Communication is documented as using SSL. MDriven Server security guidance requires HTTPS to prevent passwords and other data from being sent over an open wire; it states that security limitations are not enforced in HTTP mode. | Run MDrivenServer over HTTPS. For example, do not use HTTP for an environment where users sign in or enter customer data. Evaluate any additional transport-protection requirements for your environment. |
| A03: Injection | Data validation supports model-level OCL constraints and UI feedback for required values, data types, ranges, formats, and conditional rules. | Validate input according to the business rule. For example, use a regular-expression validation rule for an email address and a range rule for a day of birth. Input validation does not replace a review of all integrations and custom code. |
| A04: Insecure Design | MDriven Turnkey keeps the Access Control System on the server and uses declarative ViewModels and declarative rules to define the information subset for a use case. Streaming ViewModel guidance describes exposing action names to the client while the client asks the server to execute an action. | Design each ViewModel around the minimum information and actions needed for its use case. For example, expose an action named Approve to an authorized user while keeping the action implementation on the server. |
| A05: Security Misconfiguration | MDriven Server security guidance describes configuring the Admin UI to require identification, making the administrator a SuperAdmin to avoid lockout, and deciding whether exposed web services require authentication. | Require identification for the Admin UI and decide explicitly which services require authentication. For example, do not leave a service unauthenticated only because it was convenient during prototyping. Do not run production traffic in HTTP mode. |
| A06: Vulnerable and Outdated Components | No MDriven-specific component inventory, update process, or vulnerability-management procedure is documented here. | Maintain an inventory of MDriven components and all deployment dependencies, and define your own process for applying updates and reviewing vulnerabilities. |
| A07: Identification and Authentication Failures | MDriven Turnkey authentication is documented as using standard OAuth2, with optional social login or single sign-on with OpenId. OAuth2 is also documented for server-to-server authentication. | Configure authentication for the users and integrations in your use case. For example, use your OAuth2 identity provider for user authentication and apply authorization rules after authentication. |
| A08: Software and Data Integrity Failures | No MDriven-specific software-integrity, build-integrity, dependency-integrity, or deployment-verification control is documented here. | Define controls for your model-change, build, deployment, and integration processes. Treat this risk area as an application and operations responsibility until MDriven-specific guidance is available. |
| A09: Security Logging and Monitoring Failures | No MDriven-specific security-event logging, monitoring, alerting, or retention procedure is documented here. | Define which authentication, authorization, administration, and application events you need to record and review. For example, ensure your operating procedure can investigate a failed sign-in or an unexpected administrative change. |
| A10: Server-Side Request Forgery (SSRF) | No MDriven-specific SSRF control or guidance for server-side requests is documented here. | Review every server-side integration that can request a URL or external resource. Define restrictions appropriate to that integration before deployment. |
Review checklist
- List each ViewModel and identify the authenticated users and authorized use case for it.
- Verify that each ViewModel exposes only the required information subset and that filtering happens on the server.
- Configure OAuth2 authentication and the authorization rules for users and server-to-server integrations.
- Use HTTPS for MDrivenServer communication; do not rely on security limitations in HTTP mode.
- Add OCL validation rules for required, type, range, format, and conditional input requirements.
- Require identification for the MDrivenServer Admin UI and explicitly configure authentication requirements for exposed services.
- Establish application and operations controls for the OWASP areas marked as having no MDriven-specific guidance.