Platform security
The technical controls that protect your company's information inside Nodux, with enough detail for your IT team to evaluate them.
Account access
Passwords
Passwords are stored with bcrypt, a hashing algorithm built specifically for credentials: it is designed to be slow, which makes a brute-force attack against the database expensive even if someone managed to obtain it.
They are not stored in plain text or with reversible encryption. Nobody at Nodux can read a user's password, not even with direct access to the database: the hash cannot be undone.
Sessions
Each session uses a signed token that expires after 24 hours. After that, you have to authenticate again: a session left open on a shared device stops being valid on its own.
Password recovery
Recovery links are single-use and expire. Using one twice, or after it expires, does not work.
Attempt limits
Logins and password recovery are rate-limited: once the threshold is exceeded, further attempts are rejected for a window of time.
A detail that often goes wrong in other implementations: the counter lives in the database, not in server memory. When the application runs on several instances, an in-memory counter is multiplied by the number of instances and the real limit ends up much higher than the configured one. Here the count is single and shared, and it is incremented atomically.
Isolation between companies
Nodux is multi-tenant: many shops use the same installation. Making sure one shop's data never shows up on another's screen is the most important requirement of the system, and it is handled in two independent layers.
Layer 1. The application
Every query is restricted to the scope of the user making it, based on a single, centralized rule. Having just one avoids the usual problem: when each screen builds its own filter, it only takes one of them getting it wrong once.
There is also an automated test that brings up the whole system, creates two companies with different data and goes through every endpoint with all four roles, checking that none of them reaches another company's information. It runs on every code change, before publishing.
Layer 2. The database
On top of that runs PostgreSQL Row Level Security: the database applies the filter itself, on every query, without depending on the application remembering to ask for it. If a programming error left out a filter, the database still would not return another company's rows.
The application connects with a database user without superuser privileges. This is not a minor detail: in PostgreSQL a superuser bypasses Row Level Security entirely, so the policy would exist but filter nothing. With a regular user, it is actually enforced.
Transport and storage
| What | How |
|---|---|
| Browser → Nodux | HTTPS with TLS. The site is served only over an encrypted connection. |
| Nodux → database | Encrypted connection inside the provider's private network, with no exposure to the internet. |
| Files and photos | Object storage with credential-based access. Private attachments are not accessible through a public URL. |
| Backups | Encrypted at rest by the storage provider. See Backups and continuity. |
Role-based permissions
Permissions are not configured case by case: each person has a role and the role defines what they see. A simple model is harder to misconfigure.
| Role | Scope |
|---|---|
| Administrator | Their company's entire operation. The only role that can archive and perform destructive actions. |
| Agent | Their company's day-to-day operation, without the actions reserved for the administrator. |
| Sales | Their own customer portfolio. The administrator can extend it to the full portfolio. |
| Technician | The jobs assigned to them. |
| Customer | Their own equipment, tickets and documents. Nothing from other customers. |
Audit log
Sensitive actions are logged with who, what and when. The log is kept for 180 days by default, and the period can be configured if your company needs a longer one.
Monitoring
Application errors are reported automatically to a tracking system, with alerts. The goal is to find out about a failure before a user reports it.
The platform status (database, storage, email, backups) is exposed on a health endpoint that we check after every release.
What we don't have
We do not have SOC 2 or ISO 27001 certification. We say it up front, instead of letting your team find out halfway through the process. If your policy strictly requires them, you should know today and not at the final review.
What we can do: answer a security questionnaire in writing, sign a confidentiality and data processing agreement, and show how any of the controls on this page works. Write to us at soporte@nodux.link.
Reporting a vulnerability
If you find a security issue, write to us at soporte@nodux.link with the details needed to reproduce it. We will reply and tell you how it was resolved. We don't have a bounty program, but we do commit to taking it seriously and to not pursuing anyone who reports in good faith.
Related
Data handling · Backups and continuity · Privacy policy · Terms and conditions