Shipnix is scheduled to sunset on Jan 28, 2025. Please read our official statement for more information.
A strong security practice is in the best interest of Shipnix and its customers.
Shipnix has chosen to make our security policy publicly open.
We believe transparency on how we secure our servers and how we interact with the servers of the customer is vital to establish trust in the product.
Security by obscurity is seldom the most secure option in our opinion.
A Content Security Policy (CPS) is an added layer of security enforced by modern web browsers. It can detect and mitigate XSS and data injection attacks.
Shipnix has a strict CSP that is up to date with current web standards.
For example, we require a randomly generated nonce to load JavaScript and CSS. The sources of these assets also need to be specifically defined to run. This protects the customer against malware trying to inject malicious code.
The only thing the customer needs to do to take advantage of a strong CSP is to use a modern well-known web browser.
If you want to inspect our CSP, you can paste the web url of shipnix.io to in the CSP Evaluator (made by Google).
Shipnix is built on the IHP web framework and takes advantages of the Cross Site Request Forgery (CSRF) protection.
All requests a user makes from their web browser are protected under this protection
IHP by default sets its session cookies using the Lax SameSite option. While Lax sounds not very secure, this protects against all common CSRF vectors. This browser-based CSRF protection works with all modern browsers, therefore token-based protection is not used in IHP applications.
From the IHP documentation
Shipnix does not interact with externally hosted frontends, so this CSRF policy is considered to be a strong protection agains website attacks.
Shipnix is a complex application that connects to a database and interacts with external servers via SSH.
Limiting the risk for malicious user input is a top priority.
All our database queries are without exception written in the IHP framework QueryBuilder functions. This guarantees that all user input is escaped on the server-side, preventing SQL injection attacks.
We maintain a handful SSH queries through OpenSSL that takes in user inputs.
All these inputs are without exception escaped on the server-side to prevent data injection attacks that could compromise sensitive data from users with malicious intents.
Shipnix is in great favor of Multi Factor Authentication (MFA) and recommends using it everywhere possible.
We use hardware keys everywhere possible in combination with strong passwords.
All current and future staff of Shipnix are required to use MFA with hardware keys and strong passwords.
Everyone who gains access to the codebase or the servers of Shipnix are required to prove physically that they use hardware keys in a proper way, and that they have no other possible entry-points to our servers and data that could compromise the security of our users.
Shipnix supports MFA with TOTP. This is highly recommended for for strong authentication protecting sensitive server data.
Customer data is highly valuable and it's important for us to be aware of possible.
All data sent to and from Shipnix is without exception secured with SSL.
Shipnix performs periodical updates of the database and the secure SSH keys that enable Shipnix to interact with servers.
The data is secured safely in external restricted S3 storage in case of an emergency.
Backups older than one week are regularly deleted so we don't keep any customer data longer than necessary in accordance to our Privacy Policy.
Shipnix runs on NixOS, a Linux distribution with a strong focus on security.
We regularly update NixOS to be sure to take advantage of the newest security patches.
Shipnix has protection of Distributed Denial of Service (DDoS) through fail2ban.
Shipnix has logging enabled, and we regularly audit logging to detect security events or improper access.
We seek to securely improve our tooling for logging to be get notified immediately when security events occur.