Security, Encryption and Access Control

1. Application Security

The application includes a dedicated security implementation for protection against common web-based attacks. The security layer follows generally accepted industry practices and is designed to reduce the risk of unauthorized access, malicious input, and request manipulation.

The implemented security measures include protection against:

• Cross-Site Scripting (XSS): user input and output are handled in a way that helps prevent malicious scripts from being injected into pages viewed by other users.
• Cross-Site Request Forgery (CSRF): request validation mechanisms are used to help ensure that sensitive actions are performed intentionally by authorized users.
• Database Injection Attacks: all database interactions are performed using prepared statements, reducing the risk of SQL injection by separating query logic from user-supplied data.

By using prepared statements, input values are bound as parameters instead of being directly concatenated into SQL queries. This approach helps protect the system from malicious input designed to alter database queries.

2. Infrastructure and Production Protection

In production environments, the application can be additionally protected by widely used infrastructure and security services. These services may be placed in front of the application to provide an extra layer of protection before traffic reaches the server.

Depending on the deployment environment, the system can be guarded by industry-standard services such as:

• Cloudflare for DNS protection, web application firewall functionality, DDoS mitigation, SSL/TLS management, and traffic filtering.
• Amazon CloudFront for content delivery, edge-level protection, caching, HTTPS support, and integration with other AWS security services.
• Server-level firewall rules, access restrictions, HTTPS configuration, logging, and monitoring.

These services can help reduce exposure to automated attacks, suspicious traffic, excessive request rates, and other common threats affecting public web applications.

3. Encryption and Message Integrity

The software supports encryption and message verification mechanisms based on AES-256-CBC, Initialization Vector (IV) support, and HMAC, which stands for Hash-based Message Authentication Code.

AES-256-CBC is used for symmetric encryption, where the same secret key is used to encrypt and decrypt protected data. The use of a 256-bit key provides a strong encryption level suitable for protecting sensitive information when implemented and managed correctly.

CBC mode uses an Initialization Vector, commonly called an IV, to ensure that identical plaintext values do not produce identical encrypted output. The IV adds randomness to the encryption process and helps make encrypted data less predictable.

HMAC is used to verify the integrity and authenticity of protected data. While encryption protects the content from being read, HMAC helps confirm that the data has not been changed or tampered with after it was created.

In general, the encryption and verification process may include:

• Encrypting sensitive data using AES-256-CBC.
• Using an Initialization Vector to strengthen the encryption process.
• Generating an HMAC value to verify data integrity.
• Rejecting data if the verification check fails.

4. Access Control

Access control is implemented using an Extended Role-Based Access Control model, also known as Extended RBAC. This model allows permissions to be assigned through roles while still supporting detailed and flexible access rules.

The permission structure is based on a Directed Acyclic Graph, or DAG. This allows the system to represent permission relationships in a structured way, including inherited permissions, hierarchical access rules, and complex permission dependencies without creating circular permission relationships.

The access control system provides granular control over:

• Which users can access specific modules or sections of the software.
• Which resources a user can view, create, update, approve, export, or delete.
• Which actions are available to a user based on assigned roles and permissions.
• How permissions are inherited or restricted across different parts of the system.

The system can support resource-action permissions, where access is not limited only to a general role name, but can be evaluated based on a specific action performed on a specific resource. For example, one user may be allowed to view a record, while another user may be allowed to edit, approve, or delete the same type of record.

This approach provides flexible and highly detailed access management, making it possible to configure different permission levels for administrators, managers, reviewers, contributors, auditors, and other user groups.