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.
Is Moqui Secure?
Moqui provides security tools for enterprise applications, including authentication, artifact-aware authorization, record-level access controls, service input validation, and controls for limiting repeated requests. These give development teams a foundation for protecting screens, services, data, and integrations.
Moqui does not make an application secure automatically. Security also depends on how permissions are configured, how custom code is written and tested, and how the application and its dependencies are maintained after deployment.
What Is the Moqui Framework?
Moqui is an open-source framework for building enterprise applications. It provides tools for defining data entities, business services, screens, and access controls. For a fuller explanation of how those parts fit together, read our Moqui architecture guide.
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.
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
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.
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.
These rules must be designed carefully. Incorrect conditions can either expose restricted information or prevent employees from accessing records required for their jobs.
Artifact Tarpitting
Moqui includes artifact tarpitting, which can restrict how frequently specified artifacts are accessed within a defined period.
This can help control repeated requests to sensitive or resource-intensive functions.
Potential use cases include:
- Login attempts
- Password recovery actions
- High-volume service calls
- Search requests
- Data export operations
- Public API endpoints
Tarpitting should be treated as one layer of protection. It does not replace network rate limiting, web application firewalls, monitoring, or controls implemented through an API gateway.
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 framework-level controls related to common web application risks, including cross-site scripting and cross-site request forgery.
Its security features include input handling, HTML cleaning, encrypted request requirements for selected screens, and controls for sensitive actions.
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.
This execution context can help developers understand how screens, transitions, services, and entities interact.
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.
When reviewing an integration, check how it authenticates, which services it can call, what records it can access, how inputs are validated, and whether credentials and sensitive responses are protected. Test these controls with the permissions of the actual integration user, not only an administrator account.
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.
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.
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
- Use a supported framework version: Keep Moqui, Apache Shiro, Java, and other dependencies updated.
- 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.
Core Security Features in the Moqui Framework
Moqui Framework provides useful security controls for enterprise application development, including authentication, artifact-aware authorization, record-level access, service validation, and request-limiting capabilities.
These capabilities establish a strong technical foundation, but secure deployment still requires careful configuration, updated dependencies, protected infrastructure, code review, monitoring, and regular testing.
Need Help With Moqui Development and Security?
NOI Technologies provides Moqui architecture, application development, integration, migration, security review, deployment, and ongoing support services.