Skip to content

Payroll Engine Security

⚡ The Payroll Engine is a backend service and should not be used on the public Internet.

Contents

Section Description
Backend Server Security Authentication, API Key, OAuth, CORS, Rate Limiting, Script Safety, Tenant Isolation
Client Security HTTPS on localhost
Web Application Server Security User login, authorization, role-based access control

Backend server security

Authentication

The following authentication modes are available:

  • None: no authentication (default)
  • ApiKey: authentication using a key
  • OAuth: Authentication using OAuth

API Key

In the backend server configuration, a fixed key can be stored that must be included in the request header for every endpoint. This mechanism prevents unprotected access to the API.

OAuth

OAuth mode supports the following configuration options:

  • Authority — the identity provider URL
  • Audience — the expected audience claim
  • RequireHttpsMetadata — enforce HTTPS for metadata discovery
  • ClientSecret — optional client secret

On startup, the backend validates that both the authority and audience are configured. This prevents token confusion when OAuth is enabled but misconfigured.

CORS

Cross-Origin Resource Sharing is inactive by default (no cross-origin requests allowed). When enabled, the following options are available:

Setting Description
AllowedOrigins Allowed origin URLs
AllowedMethods Allowed HTTP methods
AllowedHeaders Allowed request headers
AllowCredentials Whether credentials are permitted
PreflightMaxAgeSeconds Cache duration for preflight responses

Enable CORS only when the backend is accessed from a different origin, such as a separate web application domain.

Rate Limiting

The backend supports rate limiting with two configurable policies:

  • Global policy — applies to all endpoints
  • Payrun job policy — dedicated limit for the payrun job start endpoint

Each policy is configured with PermitLimit (maximum requests) and WindowSeconds (time window). Rate limiting is inactive by default.

Script Safety Analysis

When ScriptSafetyAnalysis is enabled, the backend performs static analysis of user scripts during compilation. Scripts using banned APIs are rejected:

  • System.IO — file system access
  • System.Net — network access
  • System.Diagnostics — process execution
  • System.Reflection — reflection-based access

This is opt-in via appsettings.json due to the additional compilation overhead.

Database Collation Check

The DbCollation setting (default: SQL_Latin1_General_CP1_CS_AS) is verified on startup before the schema version check. A collation mismatch is reported as a startup error to prevent silent data integrity issues.

Cryptographic Security

Password hashing uses SHA256 with constant-time comparison to prevent timing attacks. Regular expression patterns include a timeout to prevent ReDoS (Regular Expression Denial of Service) attacks.

Tenant Isolation

To ensure multi-tenant capability, the backend server supports the HTTP header Auth-Tenant. If the optional header is present, it is compared with the tenant of the URL for each REST request. 

Auth-Tenant: "MyTenantIdentifier"

For example, the web application sets the Auth-Tenant HTTP header for all subsequent backend requests when the tenant is changed. See API Usage for details.

API Version Header

Every response from the backend includes the X-Version header, which carries the current API version: 

X-Version: 1.0
Clients can read this header to verify compatibility or for diagnostic purposes. The version follows Semantic Versioning (major.minor).

GET request body

The REST API uses HTTP POST operations for all endpoints that send potentially sensitive data in their requests. This prevents such data from inadvertently ending up in logs, browser history, or the like.

Database SQL injection

At the database level, the micro-ORM component Dapper prevents SQL Injections.

Client security

HTTPS on localhost

To use the Payroll Engine from a protected network zone, the payroll console and web application use the HTTPS protocol to communicate with the backend server. During setup, a developer certificate is installed on localhost.

Web application server security

User Login

New users are initially created by the administrator or supervisor without a password. When logging in for the first time, the user must set his password and can change this later in the user settings. This results in the following login sequence: 1. Input of the user identifier 2. Selection of the tenant - if the user identifier exists in several tenants 3. Input new password with confirmation - in case of first login 4. Input password 5. Web application start

If a user is assigned to several tenants, a separate password applies to each tenant.

User authorization

The web application distinguishes between the following user types

  • User - user of the web application with the features
  • Employee - user of the web application and wage earner (self-employment)
  • Administrator - has only the possibility to manage the users
  • Supervisor - can use all features without restriction

In the web application, the user type is indicated by the icon of the User Settings command.

Role-based access control

The functionality of the web application is controlled by Features (Feature Toggles) that are assigned to the user. Features are managed by

  • users of type Administrator
  • users of type Supervisor
  • users with the feature Users

The EmployeeCases feature allows access to employee cases by displaying an additional page in the navigation. Some features, such as Forecast, extend the content of existing pages.