Enterprise applications often manage financial records, customer information, inventory, orders, employee data, and internal business processes. Protecting this information requires more than adding a login screen or deploying the application behind a firewall.
Authentication, authorization, data access, input validation, session handling, deployment security, logging, and software updates must all be considered during development.
Moqui Framework provides built-in tools for developing enterprise applications with structured security controls. These include user authentication, role and permission management, artifact-aware authorization, record-level access rules, service validation, and controls that limit repeated access to protected application artifacts.
These capabilities provide a useful foundation, but they do not make every Moqui application secure automatically. Security still depends on configuration, custom code, infrastructure, dependency management, testing, and ongoing maintenance.
How Moqui Approaches Application Security
Moqui applies security controls to application users and to the artifacts they attempt to access.
An artifact can include:
- A screen
- A screen transition
- A service
- An entity
- A data operation
This approach allows development teams to define access rules around individual application functions instead of relying only on broad page-level permissions.
What the Framework Provides and What Teams Must Configure
| Security area | Moqui provides | Project team must verify |
|---|---|---|
| Authentication | User login and authentication tools | Account policies, MFA, sessions, and identity integrations |
| Authorization | Controls for screens, transitions, services, and entities | Permissions for each role and sensitive action |
| Record access | Record-level authorization mechanisms | Filters across customers, organizations, and other data boundaries |
| Web requests | Session-token and input-handling controls | Custom forms, APIs, output encoding, and configuration exceptions |
| Deployment | Application-level security features | TLS, network exposure, secrets, updates, and monitoring |
Core Security Features in Moqui Framework
Authentication With Apache Shiro
Moqui uses Apache Shiro for user authentication and related security functions.
Authentication verifies that a user is who they claim to be. Depending on the configuration and integration requirements, Moqui applications may use:
- Username and password authentication
- Session-based authentication
- External identity providers
- LDAP or Active Directory integrations
- Custom authentication realms
- Multi-factor authentication, when configured for the deployed Moqui version
Authentication should be combined with password policies, session controls, secure cookies, encrypted connections, account monitoring, and appropriate recovery procedures.
Developers should also keep Apache Shiro and other framework dependencies updated because authentication libraries may receive security fixes over time.
Artifact-Aware Authorization
Authentication confirms identity, while authorization determines what an authenticated user is permitted to do.
Moqui provides artifact-aware authorization for application components such as screens, transitions, services, and entities.
Authorization rules can control whether a user is allowed to:
- View an application screen
- Run a business service
- Create or update information
- Delete a record
- Access a restricted workflow
- Perform an administrative action
This provides more precise control than giving every authenticated user access to the same application functions.
User Groups, Roles, and Permissions
Moqui can associate users with groups and permissions that reflect their responsibilities.
For example, an enterprise application may define separate access for:
- Sales representatives
- Warehouse employees
- Finance users
- Department managers
- System administrators
- External customers or partners
Permissions should follow the principle of least privilege. Users should receive only the access required to perform their work.
Access should also be reviewed when employees change roles, leave the organization, or no longer require specific administrative privileges.
For sensitive business workflows, permissions should also support segregation of duties. For example, an application may require different users to create a supplier, approve an invoice, and authorize a payment. These rules must be designed and tested within the application's services and workflows.
Record-Level Authorization
Application-level access is not always sufficient. Two employees may use the same screen but require access to different records.
Record-level authorization can help restrict data based on conditions such as:
- Organization
- Business unit
- Warehouse
- Customer account
- Geographic region
- Record ownership
For example, a warehouse manager may be permitted to view inventory for one facility but not for every warehouse in the organization.
Record-level restrictions must be configured and tested for the application's data model. Permission to open a screen or run a service does not, by itself, prove that a user can see only the appropriate warehouse, customer, or organization records. Test these boundaries with accounts from each relevant role and organization.
Artifact Tarpitting
Moqui can apply configured velocity limits to selected application artifacts, including screens, transitions, and services. This can help limit repeated calls to sensitive or resource-intensive functions.
Login failure controls are separate from artifact tarpitting. A public API also needs appropriate authentication, authorization, and protection at the application and network boundaries. Tarpitting is one layer of defense, not a replacement for monitoring, a reverse proxy, or a web application firewall.
Service Authentication and Validation
Services are a central part of business logic in Moqui applications.
A service can define:
- Whether authentication is required
- Authorization requirements
- Input parameters
- Expected data types
- Validation constraints
- Transaction behavior
- Execution rules
Validating service inputs helps reduce unexpected or malformed data entering business workflows.
Developers must still validate business rules and avoid trusting input simply because it came from another internal application.
Protection Against Common Web Risks
Moqui includes controls for common web risks, but their effect depends on the request and configuration. By default, non-GET screen transitions require a session token unless that requirement is disabled for a transition. Developers must check how custom forms and integrations handle state-changing requests.
Moqui also supports parameter validation and configurable HTML handling. HTML cleaning is not a substitute for encoding untrusted data where it is rendered. Custom screens, templates, scripts, and APIs still require security review and testing.
These protections should not be interpreted as a guarantee that custom applications are free from vulnerabilities.
Developers should still:
- Validate and encode user-controlled input
- Avoid rendering untrusted HTML
- Protect state-changing requests
- Use secure session and cookie settings
- Review custom JavaScript and templates
- Test APIs and file-upload functions
- Perform security testing before deployment
Artifact Execution Tracking
Moqui maintains information about the artifacts executed during an application request or service call.
The artifact execution history is scoped to the current execution context. It is not automatically a permanent security audit log. Persistent monitoring requires appropriate logging, storage, retention, and access controls.
Application logging and execution history may support:
- Troubleshooting
- Performance analysis
- Authorization investigations
- Error analysis
- Security monitoring
Logs should be protected because they may contain usernames, identifiers, system details, or other sensitive information.
Passwords, authentication tokens, private keys, and unnecessary personal data should never be written to logs.
Securing Moqui APIs and Integrations
Moqui applications may expose services to storefronts, warehouse systems, customer portals, and other external software. Each integration should have access only to the services and data it needs.
For each integration, verify how the caller authenticates and whether it is authorized to access the REST path, underlying service, and records involved. Validate request data, restrict credentials to the required operations, and test with the integration's actual account rather than an administrator account. Protect sensitive responses and review any externally exposed endpoint separately.
Example: Testing Warehouse Access Through an API
Suppose an integration account may read inventory for Warehouse A but has no access to Warehouse B. Test the allowed request first, then change the warehouse identifier to Warehouse B and repeat the request using the same credentials.
Confirm that the second request does not return restricted inventory. Also test direct record identifiers, list filters, and export operations. Permission to call an endpoint must not allow the integration to bypass the application's record-access rules.
Security Responsibilities Outside the Framework
Moqui provides application security tools, but many important controls remain the responsibility of the implementation and operations teams.
Infrastructure Security
Servers, containers, databases, storage services, and network components should be hardened and regularly updated.
Administrative services should not be publicly exposed unless required and properly protected.
TLS and Network Protection
Production traffic should use HTTPS with valid certificates and modern TLS configuration.
Reverse proxies, load balancers, firewalls, and API gateways may provide additional network-level controls.
When Moqui runs behind a reverse proxy, verify where TLS terminates, which ports are reachable from the internet, and whether the application receives the correct information about the original HTTPS request. Moqui's HTTPS-related URL settings do not terminate TLS on their own.
Credential and Secret Management
Database passwords, API credentials, encryption keys, and service tokens should not be stored directly in source code or public repositories.
Secrets should be stored through an appropriate secret-management system and rotated when necessary.
Protecting Sensitive Data at Rest
Moqui supports encryption for selected entity fields, but those fields must be identified and configured in the application. Review which records contain sensitive information, protect database backups, and manage encryption keys outside source code. Test access to the decrypted values with the roles and services that use them.
Dependency Management
Moqui uses Java libraries and other open-source dependencies. These components should be reviewed and updated when security fixes are released.
Organizations should maintain an inventory of application dependencies and monitor relevant security advisories.
Custom Code Review
Framework controls cannot prevent every vulnerability introduced through custom services, templates, scripts, APIs, or integrations.
Code review should focus on:
- Authorization checks
- Input validation
- Output encoding
- File access
- API permissions
- Credential handling
- Error messages
- Sensitive-data exposure
Security Testing
Testing should include both normal application workflows and attempts to bypass security controls.
Depending on the application, this may include:
- Authentication testing
- Role and permission testing
- API security testing
- Session testing
- Input validation testing
- Dependency scanning
- Static code analysis
- Penetration testing
Security Checklist for a Moqui Project
- Maintain a patched framework build: Review upstream Moqui changes and security notices, update dependencies, and plan how fixes will be tested and applied to your deployment.
- Define user roles: Document which users can view, create, update, approve, export, or delete information.
- Apply least privilege: Avoid giving users or integrations broader access than required.
- Protect sensitive artifacts: Configure authorization for screens, transitions, services, entities, and administrative tools.
- Review record-level access: Test permissions across organizations, facilities, customers, and other data boundaries.
- Secure APIs: Require authentication, validate input, limit requests, and protect credentials.
- Use HTTPS: Encrypt production traffic and protect cookies and sessions.
- Manage secrets securely: Keep credentials and keys outside source code.
- Protect logs: Avoid recording passwords, tokens, and unnecessary personal data.
- Test custom code: Review extensions, integrations, templates, and services before release.
- Monitor production activity: Track authentication failures, authorization failures, errors, and unusual request patterns.
- Maintain backups: Test database and file recovery procedures regularly.
Moqui Security References
- Moqui security documentation for authentication, artifact authorization, record access, and tarpitting.
- Moqui framework security policy for supported code and vulnerability reporting.
- Moqui attack surface documentation for request paths, security controls, and deployment boundaries.
Need Help Securing a Moqui Application?
We can review a Moqui application's architecture, permissions, integrations, and deployment setup, then help your team address the issues found.