Security

Report a vulnerability

Found a security issue? Email security@proezi.com with the steps to reproduce it. Please give us a chance to fix it before sharing it publicly, and do not access or change other people’s data while testing.

Signing in

• Owners and workspace members sign in with Google only. Proezi asks Google for identity scopes only (your account ID, name, email and profile image) and has no password system for ordinary users — there is no Proezi password to steal or reuse.
• Platform administrators use a separate email-and-password sign-in. Passwords are stored only as Argon2id hashes, repeated failures trigger a progressively longer lockout, and failed attempts are recorded.
• Session cookies are HTTP-only, sent over HTTPS only, and same-site. Account status and roles are re-checked on every request, so suspending an account or removing a role takes effect immediately.

Workspaces stay separate

• Every change is authorized on the server: Proezi checks that you are an active member of the workspace and that your role allows the action, before anything is read or written. Hiding a button is never the only protection.
• Items belonging to another workspace are treated as if they do not exist. Automated tests attempt management actions against other workspaces and require every one of them to be refused.
• Public links use random identifiers, never sequential numbers, and unknown, unpublished and archived links all return the same “not found” page.

Published pages

• Visitors see an immutable published copy built from a fixed list of public fields. Workspace, member and account details are never part of it, and drafts are never shown to visitors.
• Visitors need no account. Arrival pages carry no advertising or third-party analytics scripts; visit counts are anonymous, and no visitor IP address is stored.
• Payment and business identity pages are always hidden from search engines. Proezi never processes payments, and business numbers are labelled as format-checked, never as registry-verified.

In the browser

• HTTPS everywhere, with HTTP Strict Transport Security so browsers refuse plain connections.
• A per-request Content Security Policy: only scripts carrying that request’s one-time code can run, so injected scripts are blocked even if they reach the page. Pages cannot be framed by other sites (the opt-in embed card is the only exception).
• Content you type is always displayed as text, never as HTML, and forms only accept requests from Proezi itself.

Uploaded photos

Every image is checked for size before it is decoded, decoded from its actual contents (not its file name), re-encoded into a fresh file, and stripped of all metadata — including GPS location. Files get random names and are stored outside the web application’s public folders.

Abuse limits, logs and backups

• Rate limits protect visitor buttons, feedback, uploads and the administrator sign-in, backed by per-address limits at the web server.
• Platform administrator actions — such as suspending an account or workspace, or taking down a page — require a written reason and are recorded in an audit log, as are key workspace changes such as publishing.
• Logs are scrubbed of passwords, tokens and cookies before they are written.
• The database and uploaded media are backed up nightly, with a documented restore procedure.

Related

See the Privacy Policy for what we store, the Acceptable Use Policy for what may be published, and live system status.