Back to overview

Application Security

Developer Tutorials Published on 01.11.2025

Application Security Guide

This guide provides a comprehensive overview of the security features implemented in the application to protect your data and ensure a safe user experience.

1. User Authentication and Access Control

The application is built with a robust authentication system to ensure that only authorized users can access data.

1.1. Registration and Login

  • Secure Registration: New user registrations require a unique username and email address. The system checks for existing accounts to prevent duplicates.
  • Rate Limiting: To prevent brute-force attacks, the number of login attempts, registration requests, and password reset requests from a single IP address is limited within a specific time window. If the limit is exceeded, further attempts are temporarily blocked.

1.2. Password Security

The application enforces password complexity rules which can be configured by the administrator. The language file suggests different levels of security:

  • Standard: At least 8 characters.
  • Medium: At least 8 characters and must contain numbers.
  • High: At least 8 characters, with uppercase and lowercase letters, numbers, and special characters.

Passwords are never stored in plain text. They are securely hashed using modern, strong hashing algorithms before being saved to the database.

1.3. Two-Factor Authentication (2FA)

For an added layer of security, users can enable Two-Factor Authentication in their profile (My Profile → Login Data). When 2FA is active, logging in requires both the user's password and a time-sensitive 6-digit code sent to their registered email address.

Tip: We highly recommend all users enable 2FA to significantly increase their account security.

1.4. Password Reset

If a user forgets their password, they can use the "Forgot password?" link on the login page. They will receive an email with a secure, time-limited link to set a new password. The reset token expires after one hour to prevent misuse.

2. User and Rights Management (Administration)

Administrators have powerful tools to manage users, groups, and permissions, ensuring that access to data is strictly controlled.

2.1. User Management

Administrators can view, create, edit, and delete users. They can also:

  • Impersonate Users: Admins can temporarily log in as another user to see the application from their perspective. This is invaluable for troubleshooting and support. An info bar is always visible during impersonation, and the admin can return to their own session with a single click.
  • Deactivate Users: Instead of deleting, an admin can deactivate a user, which archives their account and revokes their license without losing historical data.

2.2. Group-Based Rights Management

The application uses a flexible, group-based permission system. The workflow is as follows:

  1. Create Groups: Admins define user groups (e.g., "Sales", "Accounting", "Project Managers").
  2. Assign Users: Users are assigned to one or more groups.
  3. Define Rights: For each group, admins can grant specific permissions on a per-table basis. Permissions include:
    • View: Can see records.
    • Add: Can create new records.
    • Edit: Can modify existing records.
    • Delete: Can delete records.
    • Print, Import, Export: Access to data handling features.

If no specific rule is defined for a table and a user's group, access is granted by default. However, if any rule exists for that table, access becomes "deny-by-default," and permissions must be explicitly granted. An explicit can_view = No rule for a group will always deny access to that table for its members.

2.3. Demo Mode

The application includes a special "Demo" user type. For testing and evaluation purposes, demo users have broad permissions to explore the application's features, but their access may be time-limited.

3. Data Security and Isolation

The application is designed with multi-tenancy in mind, ensuring that data from different teams is kept separate and secure.

3.1. Team-Based Data Segregation

Most data, including custom tables, value lists, and preferences, is tied to a specific team. The physical database tables for custom data are named using the team and table ID (e.g., data_team_mycompany_123), providing a strong layer of separation.

3.2. Shared Tables and Team Fields

In some cases, an administrator might create a central table (e.g., a list of countries or products) that should be accessible to multiple teams. This is handled by assigning the table to a special ADMININTEX team.

When a non-admin user from another team accesses this shared table, the system automatically filters the data to show only records relevant to their team. This is typically done by checking a team column in the data.

How to automatically fill a team field:

To ensure new records in a shared table are correctly assigned to the creator's team, you can use a Formula field.

  1. Create a Text field with the technical name team.
  2. Create a Formula field.
  3. In the formula field's options, enter the following expression: {{ TEAM }}.
  4. Set the "Target Field" for the formula to your team field.
  5. Mark the formula field itself as "Invisible (calculation only)".

Now, whenever a new record is created, the formula will automatically retrieve the current user's team name and populate the team field, which can then be used for filtering and rights management.

4. Application and Code Security (Under the Hood)

Beyond user-facing features, the application incorporates several crucial security measures at the code level.

4.1. Protection Against Common Vulnerabilities

  • Cross-Site Scripting (XSS): All user-provided output is escaped by default. For features that require user-input to be rendered as HTML (like in Parsedown for Markdown), a "Safe Mode" is engaged to sanitize the input and prevent malicious scripts from being injected.
  • SQL Injection: All database queries are executed using PDO prepared statements. This means user input is never directly included in SQL queries; instead, it is sent separately and safely bound as parameters. This is the industry-standard defense against SQL injection.
  • Cross-Site Request Forgery (CSRF): All forms that perform actions (like creating, updating, or deleting data) include a hidden, unique, and session-specific CSRF token. The server validates this token upon submission. If the token is missing or invalid, the request is rejected. This ensures that actions can only be initiated from within the application itself, not from a malicious external site.

4.2. Secure Custom Scripting

The application allows for powerful customization through Custom Buttons and Events that can execute scripts. To maintain security, it's vital to write these scripts defensively.

Writing Secure Button/Event Scripts:

  1. Use Server-Side Validation: Never trust data coming from the client ($_GET, $_POST). Always validate permissions and data on the server before performing any action. Use the check_user_permission_for_table_id() function to verify that the current user is allowed to access the table they are trying to act upon.

    // Example: A script triggered by a button
require_once '../init.php'; // Includes security checks

$table_id = (int)($_GET['table_id'] ?? 0);
$record_id = (int)($_GET['id'] ?? 0);

// 1. ALWAYS check permission first!
if (!check_user_permission_for_table_id($table_id)) {
    die("Access Denied.");
}

// 2. Get the record and perform your action
$table = get_table_by_id($table_id);
$physical_table = get_physical_table_name($table['table_name'], $table['team']);

// Use DB functions for safe updates
DBUpdate($physical_table, ['status'], ['completed'], $record_id);

// Redirect back with a success message
redirect_to_record($table_id, $record_id, 'status=updated');
  2. Use the Database Functions: Always use the provided DBInsert(), DBUpdate(), DBGet(), and DBDelete() functions. They are built to use prepared statements and protect against SQL injection.
  3. Sanitize Formula Inputs: The evaluate_formula() function has built-in security checks. It uses a whitelist of allowed characters and functions, and blocks potentially dangerous code (like semicolons or direct variable access) to prevent injection attacks through formula fields.

By understanding and utilizing these layered security features, you can ensure your application and its data remain safe and protected.