Security

Last updated 28 July 2026

This page describes how Cinderra is built to keep your boards yours, and how to tell us if you find a way around it. It is written plainly rather than as a list of certifications we do not hold.

01Who can read your boards

Access control is enforced by the database, not by application code. Every table has row-level security enabled, and every policy checks the identity in your signed session token against the row being read or written. A request for a board that is not yours is refused by PostgreSQL itself.

This matters because the usual way board data leaks is a missing check in one endpoint out of forty. Here there is no endpoint to forget: the rule lives next to the data.

Uploaded files are stored under a path beginning with your user identifier, and the storage policy verifies that segment against your session. Someone who guesses a filename still cannot read it.

02In transit and at rest

All traffic is HTTPS, with HTTP redirected. Data is encrypted at rest by our database and storage provider using AES-256.

Passwords are hashed with bcrypt by our authentication provider. We never see a plaintext password, and neither does any code we wrote.

Sessions are short-lived tokens with refresh, held in HTTP-only cookies in the web app and in extension storage in the clipper. Signing out revokes them.

03In the application

A strict content security policy on the extension’s own pages, which forbids remote scripts entirely.
No third-party scripts on the web app: no analytics, no tag manager, nothing that could be compromised upstream and inject into your session.
Card content is rendered as text, never as markup, so a note containing a script tag is a note containing a script tag.
Payments go through PayPal’s own flow; card numbers never reach our servers.
Dependencies are kept few and deliberate. The extension has none at all — every byte that ships is readable in the repository.

04The extension specifically

The clipper installs with access to no website. Reading a site is a permission you grant per site, at the moment you first try to clip from it, and revoke from the options page. The in-page badge only appears on sites you allowed.

Sign-in uses OAuth with PKCE, in a window Chrome owns and the extension cannot read. The extension never handles a password, which is also why it does not offer a password field.

05Operationally

Backups run daily and are encrypted; restores are tested. Backup snapshots roll over on a 30-day cycle, which sets the outer bound on how long deleted data can survive.

Access to production is limited to people who need it, protected by multi-factor authentication, and used for operating the service — not for reading board content.

Server logs are kept for up to 30 days for debugging and abuse investigation.

06What we do not claim

Northem is a small operation. We are not SOC 2 certified, not ISO 27001 certified, and we do not run a bug bounty with a payout table. Anyone telling you otherwise about a service this size is usually stretching it.

What we do have is a small, readable codebase, a database that enforces its own access rules, and no third-party code running in your session. If you need a formal certification for procurement, we would rather tell you now than after you have signed something.

07Reporting a vulnerability

Email admin@northem.no with the words “security report” in the subject. Include what you found, how to reproduce it, and what you think the impact is. If you would like credit, say so.

We will acknowledge within 3 working days, tell you our assessment within 10, and keep you updated until it is fixed.

We will not pursue legal action against anyone who reports a finding in good faith, stays within their own account, does not access or modify other people’s data, does not degrade the service, and gives us a reasonable chance to fix the problem before publishing. Please do not run automated scanners against production, and do not test denial of service.

There is no cash bounty. We will thank you properly and, with your permission, credit you here.

08If something goes wrong

If a breach occurs that is likely to result in a risk to people’s rights and freedoms, we will notify Datatilsynet within 72 hours of becoming aware of it, and tell affected users directly without undue delay. Business customers with a data processing agreement are notified within 48 hours.

The notice will say what happened, what data was involved, what we have done, and what you should do. It will not be a press release.

TL;DR

In short

The database itself refuses to hand over someone else’s board, everything is encrypted in transit and at rest, and we would rather tell you what we do not have than imply we do.

AccessRow-level security on every table, so an unauthorised read is rejected by the database rather than by application code that might have a bug in it.
EncryptionTLS in transit, encrypted at rest, passwords hashed. Board content is not encrypted end-to-end — we could read it if we chose to, and we say so rather than implying otherwise.
The extensionNo permission to read a site until you point it at one, and it holds a session token in extension storage that no web page can reach.
What we lackNo SOC 2, no ISO 27001, no bug bounty payouts. We are small, and pretending otherwise would be the actual risk.
Found a holeEmail admin@northem.no with “security report” in the subject. Acknowledged in 3 working days, assessed within 10, and no legal action for good-faith research.
If we are breachedDatatilsynet within 72 hours, you without undue delay, business customers with a DPA within 48. The notice will say what actually happened.

This summary is here to be read, not relied on. It is not part of the Security and it does not change a word of what is above it — where the two disagree, the document wins.