How to secure your Salon Booking OS installation

This page lists the measures Salon Booking OS by OsDot™ applies and what you should configure. It makes no certification claim.

Transport #

• Serve the site over HTTPS only. The installer refuses plain HTTP on a public host, and sessions use secure cookies.
• Behind a proxy that ends HTTPS, trust only that proxy (the installer shows the setting to add); the site then reads the proxy’s X-Forwarded-Proto.

Security headers #

Every page carries a strict Content-Security-Policy (scripts only with the page’s own nonce), X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin and a Permissions-Policy that switches off the camera, the microphone and location by default. API answers are never cached and send no referrer.

Over HTTPS every answer also carries Strict-Transport-Security: max-age=31536000 (one year): a browser that has visited the site goes straight to HTTPS from then on, for a year after its last visit. It is not sent over plain HTTP or on a site that runs on this computer only, and a header your host or CDN sets itself is kept. Keep the site’s HTTPS certificate valid and renewed: while the header is in force, browsers refuse to open the site without a valid certificate, with no way for a visitor to click past the warning.

Hosting features and CDNs must not replace these headers. Some add their own Content-Security-Policy and thereby remove the site’s; switch such a feature off, or make it pass the site’s headers through.

Files and permissions #

• Document root Web/webroot/ and nothing above it; where the parent folder must be served, keep the shipped .htaccess files, which deny config/, storage/, tmp/ and logs/.
• config/app_local.php holds the security salt and the database password: readable only by the web server’s and the scheduler’s user (0640 or 0600). The installer writes it as 0600 where the platform allows.
• storage/ holds the encryption key of the saved provider settings, the private files and the logs: writable by the web server, never readable by other accounts on the host.
• Keep the application’s code (src/, templates/, vendor/, webroot/) read-only for the web server’s user where your hosting allows it, except the folders that receive uploads.

Database #

• A dedicated database and user with exactly the privileges in System requirements; no global privileges.
• Connect over a local socket or a private network; never expose the database server to the internet.

Accounts and sign-in #

• The owner account is the one you create in the installer; a clean installation has no default or demo account.
• Sign-in attempts, one-time codes and links are rate-limited per account and per address; codes and links expire, and are deleted 30 days after they expired.
• The owner’s web sign-in can take a second step, a code sent by e-mail, where the product turns it on.
• Staff work with roles and permissions; review them before you invite staff.
• A client can ask for the account’s deletion; once the business completes it, the account’s personal data is removed and the business’s own records (orders, visits, messages) stay without the person.

Stored secrets #

The SMTP password, the payment providers’ secrets, sign-in providers’ secrets and other provider keys are stored encrypted with the installation’s own key (storage/keys/integration.key) and never shown again after saving. Back the key up with the database (see Backups).

Scheduled work #

Run the scheduled commands as the web server’s user or one in its group, never as root (see Scheduled tasks).

Updates #

Apply updates as described in Installation: installing an update, after a backup. The administration area’s notice says when the PHP or database version is past its end of life.

Reporting a security issue #

Report a suspected vulnerability privately to OsDot Solutions through the support channel on osdots.com, not in a public forum. Include the version from VERSION and the steps to reproduce.