Security

Enchamber is built for sharing sensitive documents. This page describes the technical controls that protect your data — what we encrypt, what we cannot see, where data is stored, what we log, and how we respond to security incidents. We keep these claims factual and update this page whenever our security posture changes.

Both your account password and any share password you set are hashed before storage. We use bcrypt (10 rounds) with a SHA-256 pre-hash — this avoids a well-known bcrypt 72-byte truncation behaviour on long passwords.

We never store passwords in plain text. Enchamber staff, including the founder, cannot see or recover your passwords at any point. If you forget your account password you can reset it via email. If you forget a share password you must create a new share.

Files you upload are stored in a private Cloudflare R2 bucket. The bucket has no public read access — files are not directly reachable by their storage path.

When a recipient enters the correct share password, our server generates a time-limited cryptographically signed URL that expires after 1 hour. This signed URL is the only way to access the file bytes, and it cannot be generated without a verified password check on the server.

To protect recipients from accidentally executing malware, we reject uploads with extensions that auto-execute on common operating systems. The check runs both in the browser and on our server.

Currently blocked: .exe .bat .cmd .com .dll .msi .scr .pif .vbs .wsf .cpl .ps1 .psm1 .hta (Windows), .sh (Linux/Unix), .app .dmg .pkg .iso (macOS / disk images), .php .asp .jsp (server-side scripts).

Archives (ZIP, RAR), installers for non-consumer-OS platforms (APK, JAR, DEB, RPM), and standard documents/media are accepted normally. We rely on the recipient's OS sandboxing for archive contents — we do not inspect inside ZIP files.

No file data, share content, or download URLs ever appear in the initial page response. The public share page first loads only the password form. Content is returned by the server only after it verifies a valid, unexpired session cookie that was issued after a successful password check.

Session cookies are marked httpOnly (cannot be read by JavaScript — this protects against cross-site scripting attacks stealing the cookie), secure (sent only over HTTPS), and sameSite=lax (a standard protection against cross-site request forgery).

All traffic between your browser and Enchamber is encrypted using HTTPS/TLS. Plain HTTP requests are automatically upgraded to HTTPS by our hosting provider.

A Content Security Policy (CSP) header is set on every page. It restricts the origins from which scripts, styles, fonts, images, and network requests can be loaded — reducing the blast radius of any injected content.

Password protection is strong against unauthorised access. It is not a defence against every risk. We want to be clear about what is outside the scope of what Enchamber can do:

• We cannot protect against weak or reused passwords you set on a share. Choose a strong, unique password when the content is sensitive.
• We cannot recover a share password you forget. There is no reset mechanism by design — if the password is lost, you will need to create a new share.
• Once a recipient enters the correct password, they can screenshot, copy, or save the content. Password protection prevents unauthorised access; it does not prevent an authorised recipient from doing what they want with the content once they have it.
• We cannot protect against malware, keyloggers, or compromised devices on your side or the recipient’s side. Device security is outside our control.

Enchamber uses a small number of named sub-processors to run the service. Each is disclosed in our Privacy Policy and bound by their respective Data Processing Agreements.

We retain application, authentication, and access logs for at least 180 days, as required under the CERT-In Directions, 2022. Logs are stored by our hosting provider (Railway).

What we log: API request timestamps and endpoints, authentication events (sign-in, sign-out, account creation, account deletion), and share access events (view, download).

What we never log: account passwords, share passwords, file contents, session cookie values, or signed file URLs.

If we detect a security incident affecting personal data, we report it to the Indian Computer Emergency Response Team (CERT-In) within 6 hours of detection, as required by the CERT-In Directions, 2022, and notify affected users without undue delay.

Incident types that trigger this process include unauthorised access to systems or data, data breaches, malware or ransomware attacks, website defacement, identity theft or phishing targeting our platform, and denial-of-service attacks.

If you believe you have found a security vulnerability in Enchamber, please email hello@enchamber.com with the subject line “Security Vulnerability”. Please include a description of the issue, steps to reproduce it, and contact details for follow-up.

We commit to:

• Acknowledging your report within 24 hours.
• Keeping you updated on our investigation and fix progress.
• Crediting you in a public disclosure on resolution, if you wish.
• Not pursuing legal action against good-faith security researchers.

Please do not publicly disclose the issue until we have had a reasonable opportunity to investigate and fix it. Our standard disclosure window is 90 days from the date we acknowledge your report.