Technical Security
Security Standards
MKWork Manager is built with security as a design priority. This document describes the technical and organizational measures implemented to protect your organization's data.
AES-256-GCM Encryption
Uploaded files are encrypted individually per organization with unique HKDF-SHA256-derived keys.
2FA Authentication (TOTP)
Native support for Google Authenticator / Authy per RFC 6238. Activatable per user.
Multi-tenant isolation
Each organization has a separate PostgreSQL schema. No cross-tenant interaction possible through the application.
Complete audit log
All sensitive actions are logged with user, IP, timestamp, and full details.
CSP + Security Headers
Content-Security-Policy with unique nonce per request, HSTS, X-Frame-Options, Referrer-Policy.
Rate Limiting
Attempt limit on login and sensitive endpoints, with automatic blocking of abusive IPs.
01 Authentication and session management
| Measure | Technical details |
|---|---|
| Hashed passwords | bcrypt with high cost factor — resistant to brute-force and rainbow table attacks |
| 2FA TOTP | Per RFC 6238, compatible with Google Authenticator, Authy, and any standard TOTP app. Activatable per user. |
| Server-side token | At login, a random token is generated and stored server-side. Each request verifies the token timing-safely — stolen sessions become invalid immediately on logout |
| Secure cookie | HttpOnly, SameSite=Lax, Secure — inaccessible from JavaScript, protected against CSRF and MITM |
| Session fixation | Session ID regenerated on every successful authentication |
| Full logout | On logout, the session token is invalidated server-side — stolen sessions can no longer be reused |
| Login lockout | After multiple failed attempts, authentication is temporarily blocked per IP and per account |
02 Data and file encryption
Files uploaded to the application (technical drawings, PDFs, GCode files, 3D models, etc.) are encrypted at rest when the organization has encryption enabled.
| Element | Applied standard |
|---|---|
| File encryption algorithm | AES-256-GCM — authenticated, resistant to unauthorized modification |
| Per-organization key | Each organization has a unique cryptographic encryption key — compromising one tenant does not affect others |
| Unique nonce | Cryptographic nonce generated randomly per file — guarantees encryption uniqueness even for identical files |
| SMTP password | Stored encrypted in the database, never in plaintext |
| Webhook secret | Encrypted at rest, decrypted only at send time; signed HMAC-SHA256 on every outbound request |
| Application key | Required explicitly in production — the application refuses to start without it, preventing deployments with unsafe keys |
03 Multi-tenant isolation
MKWork's architecture ensures complete data separation between organizations at the database level.
- Each organization has a separate database schema — no shared tables between tenants
- Database sessions are strictly bound to the authenticated organization — no cross-tenant access possible through the application
- Platform administration data is completely separated from clients' operational data
- Encryption keys are individually derived per organization — compromising one account does not expose other organizations' data
- Every request verifies resource ownership against the current organization before any operation
04 Web application security
| Attack vector | Implemented protection |
|---|---|
| CSRF | CSRF token on all POST forms with automatic expiry; REST API protected by dedicated authentication, separate from browser session |
| XSS | Content-Security-Policy with nonce unique per request and strict-dynamic — unauthorized inline scripts are blocked by the browser even if injected |
| SQL Injection | SQLAlchemy ORM with parameterized queries — no raw SQL with user-supplied data |
| Path Traversal | Validation of os.path.realpath() on all file paths before operations; werkzeug.utils.secure_filename() on uploaded filenames |
| Open Redirect | The next parameter from login is strictly validated — only relative same-origin URLs accepted |
| Clickjacking | X-Frame-Options: SAMEORIGIN — page cannot be embedded in an iframe from other domains |
| MIME Sniffing | X-Content-Type-Options: nosniff — browser respects the declared MIME type |
| Information Disclosure | Error messages do not reveal internal details (stack trace, versions, DB structure) to unauthenticated users |
05 Uploaded file validation
Files uploaded by users are subject to multiple levels of validation before storage:
- Magic bytes validation — the actual file content is verified (first bytes), not just the declared extension; a
.pdffile with executable content is rejected - Allowlisted file types — only explicitly permitted formats are accepted per context (PDF, DXF, STL, STEP, GCode, etc.)
- SHA-256 checksum — calculated at upload; detects duplicates and verifies integrity at download
- Storage quota — each organization has a configurable space limit per plan; uploads are rejected if the quota is exceeded
- VPS disk monitoring — uploads are automatically blocked globally when free server space drops below the critical threshold
- Path traversal — file paths are validated with
realpath()before writing or reading
06 HTTP Security Headers
Every HTTP response includes the following security headers:
| Header | Value / Effect |
|---|---|
| Content-Security-Policy | nonce-{random} per request, strict-dynamic — prevents XSS through unauthorized scripts |
| Strict-Transport-Security | Forces long-term HTTPS connections for the domain and subdomains |
| X-Frame-Options | SAMEORIGIN — prevents clickjacking |
| X-Content-Type-Options | nosniff — prevents MIME sniffing |
| Referrer-Policy | strict-origin-when-cross-origin — limits information sent during cross-domain navigation |
| Permissions-Policy | geolocation=(), camera=(), microphone=() — disables access to sensors and peripherals |
07 Rate Limiting and brute-force protection
- Login — limited number of requests per IP with automatic blocking after the limit is exceeded
- Account lockout — after multiple consecutive failed attempts, authentication is temporarily suspended per IP
- REST API — rate limit per endpoint, responses include information about the remaining limit
- Public forms — public endpoints have separate, more restrictive limits
Brute-force protection is active both per IP and per account, preventing distributed and targeted attacks.
08 Security of external integrations
| Integration | Security measures |
|---|---|
| Outbound webhook | Signed HMAC-SHA256 with unique per-client secret, stored encrypted. SSRF validation: URLs to private networks and localhost are automatically rejected. |
| SMTP email | SMTP credentials stored encrypted, never in plaintext. SSL/TLS certificate verification active by default. Email headers are sanitized against header injection. |
| Client access link | Random cryptographic token with configurable expiry. Read-only access to order status, no sensitive data. |
| REST API | API keys are associated with a user and have defined scopes (read / write). They can be revoked at any time. All calls are recorded in the audit log. |
| SSO / SAML 2.0 | Configurable per organization (Enterprise plan). IdP metadata is validated at configuration time. |
09 Role-based access control (RBAC)
Each user has a role with a set of permissions. Access to resources is verified at route level and at object level.
| Role | Main access |
|---|---|
| Operator / User | Work on own parts, own timesheet, order viewing |
| CTC | Quality, NCR, CoC, view all parts |
| Director | View reports and KPIs |
| Production manager | Production management, assignments, planning |
| Moderator | Create/edit parts, projects, timesheets for all employees |
| Admin | Full access to organization, users, settings |
Platform administration accounts are completely separate from organization accounts and have no implicit access to clients' operational data.
10 Audit Log
All sensitive actions are automatically logged in the organization's audit log (available on Pro and Enterprise plans).
- What is logged — authentications, user changes, part and project creation/editing/deletion, settings changes, API actions, security events
- What an entry contains — category, action, description, user, IP address, UTC timestamp, severity
- IP detection — support for deployments behind a reverse proxy, with correct detection of the real IP
- Audited areas — authentication, users, projects, parts, materials, quality, administration, API, billing, security
The audit log is per organization — each tenant has its own complete history, isolated from other organizations.
11 Scanner and bot detection
- Automatic scanning activity is detected and blocked
- Access attempts to non-existent paths or paths specific to other platforms are logged and monitored
- Scanning activity is logged for subsequent analysis
12 Vulnerability reporting
If you have discovered a security vulnerability in MKWork Manager, please contact us before public disclosure:
Security email: contact@mkwork.ro
We respond within a maximum of 72 hours. Confirmed vulnerabilities are fixed as a priority, before any other tasks.
Our responsible disclosure program requires:
- Do not access, modify, or delete other users' data
- Do not perform DoS attacks or any action that may affect service availability
- Report the vulnerability privately before any public disclosure