Security at Clicbase, end to end

Clicbase hosts real data: accounts, content, even payment credentials. Here's how it's protected, layer by layer, from the database all the way to the server.

Security isn't just one feature among others: it's a baseline requirement when you're hosting customer data. This article documents, without glossing over anything, the measures in place at every level of the platform.

The guarantees at a glance

• One isolated database per project, no data shared between customers.
• Encryption in transit (HTTPS/TLS everywhere) and of secrets (AES-256).
• RLS: each user only sees their own rows, enforced inside the database.
• Hashed passwords (never in plain text), hardened server (key-based SSH, UFW, fail2ban).
• Authenticated email (SPF/DKIM/DMARC) and daily backups.

---

1. Data isolation

Each project has its own PostgreSQL database, in its own dedicated space. No data is mixed between customers: this is real isolation, at the database level, not just an application-level filter. That's essential for confidentiality and for GDPR.

Why one database per project, A forgotten filter in application code can expose another customer's data. Physically separate databases make that kind of leak impossible by design.

---

2. Encryption in transit

All traffic runs over HTTPS/TLS. Certificates are managed automatically (Let's Encrypt via the reverse proxy), and the front-facing CDN enforces an end-to-end encrypted connection all the way to the origin. No data travels in plain text over the network.

3. Encryption of secrets

API keys and sensitive credentials (Stripe, PayPal, SMTP…) are encrypted with AES-256 and stored per project in a vault. They are never shown in plain text, never logged, never committed. Only authorized edge functions can decrypt them at runtime.

Payment credentials, A site's Stripe/PayPal keys are encrypted and isolated per project. A payment credential never appears in plain text, anywhere, not in the database, not in the logs, not in the code.

---

4. Authentication & data access

Authentication (email/password, Google) issues a token per user. That token is then checked against Postgres row-level security (RLS): the "everyone only sees their own data" rule is enforced at the core of the database, so it can't be bypassed from the front end.

🔑 Passwords: always hashed (Available)

A password is never stored in plain text, only its hash is. When migrating from Supabase, hashes are carried over as-is and transparently re-hashed at login. No one, not even us, can read a password.

---

5. Server hardening

The host machine is hardened: key-based SSH only (password and root login disabled), a UFW firewall (only ports 22, 80, and 443 open), and fail2ban, which bans repeated intrusion attempts.

Measure	Detail	Status
SSH	Key-based only, root and password disabled	Available
Firewall	UFW, ports 22/80/443 open, everything else blocked	Available
Anti-intrusion	fail2ban (automatic banning)	Available
Project isolation	Dedicated Docker container (optional)	Available

---

6. Authenticated email

Emails sent from your domain are signed and authenticated: SPF declares the authorized servers, DKIM signs every message, DMARC handles failures. The result: your emails land in the primary inbox and can't be spoofed.

---

7. Backups & resilience

Each database is automatically backed up every day (pg_dump), dockerized containers included. If something goes wrong, a database can be restored to its state from the day before.

---

In summary

From database isolation to server hardening, by way of encryption and RLS, Clicbase security is designed in depth, each layer protects the next.

The best security is the kind you don't have to configure yourself: it's there, by default.

Questions about a specific point? Create an account and take a look at your dashboard, most of these protections are already active, with nothing to set up.