🛡️ Our fundamental guarantee
The best way to protect your files is to never receive them. Ziphay's core engine processes all files locally in your browser — no file data is ever transmitted over the network.
🔒
HTTPS / TLS 1.3 Already enabled
All data in transit is encrypted end-to-end. Firebase enforces HTTPS by default with TLS 1.3 — protecting against man-in-the-middle attacks with zero extra configuration.
🌐
Browser-side Processing Already live
Ziphay's core engine never uploads files to a server. Files stay in the user's browser memory — zero upload means zero upload attack surface. The safest possible architecture.
🚦
Rate Limiting + File Validation Add with Pro
When Pro backend uploads are added: validate MIME type server-side, cap file sizes, rate-limit per user (e.g. 10 req/min), and reject executables and archives with malware signatures.
🗄️
Firebase Storage Encryption Free, automatic
All files in Firebase Storage are encrypted at rest with AES-256 automatically. Google manages the keys. No code required — it's on by default.
🔑
Client-side Encryption Add for Pro
Before uploading, encrypt the file in the browser using AES-256-GCM (Web Crypto API). Only the user holds the decryption key — even Ziphay cannot read the file. True zero-knowledge storage.
⏱️
Auto-deletion Policy Add with Pro
Firebase Cloud Functions trigger a scheduled job to delete all uploaded files after 1 hour. Files are not kept longer than needed — this is Ziphay's core privacy promise.
3
Access Control Security
🛡️
Firebase Security Rules Already configured
Firestore and Storage rules ensure users can only access their own files. No user can read, write, or delete another user's data — enforced server-side, not just in the UI.
🎟️
Signed URL Downloads Add with Pro
Pro files are served via short-lived signed URLs (15 min expiry). The URL is useless after expiry — prevents hotlinking and unauthorized sharing of processed files.
🧪
Server-side MIME Validation Add with Pro
Never trust browser-reported file types. On the backend, re-read the file's magic bytes to verify its real type. Reject disguised executables (e.g. .exe renamed to .png).
When a user uploads a file, the backend computes a SHA-256 hash and writes it to a blockchain. This creates a permanent, tamper-proof record: "This file existed at this timestamp, owned by this wallet." The file itself is never on the blockchain — only its fingerprint.
→
→
⛓️
Hash written to blockchain
→
🧾
Tx hash returned to user
→
✅
Proof of ownership forever
What blockchain proves Real value
- This exact file existed at this timestamp
- This user was the first to process it
- The file has not been tampered with since
- Ownership is publicly verifiable by anyone
What blockchain cannot do Misconception
- Protect the file during transfer
- Encrypt the file content
- Prevent unauthorized access
- Replace HTTPS or Firebase Rules
Recommended Blockchain: Polygon (MATIC)
💜 Polygon Network Recommended
Ethereum-compatible L2 chain. Gas fees are fractions of a cent (vs $5–$50 on Ethereum mainnet). Fast finality (~2s). Widely supported. Free testnets for development.
🔷 Alternatives
Solana — fastest, cheapest, but different SDK.
Ethereum — most trusted, but expensive gas.
IPFS + Filecoin — decentralised file storage, not just hashing.
Full Pro Security Stack — Build Order
1
Firebase Rules ✓ Already done
Firestore & Storage security rules enforce per-user access control.
2
Rate Limiting Cloud Functions
Throttle API requests per user to prevent abuse. 10 req/min default ceiling.
3
MIME Validation FastAPI / Node
Server-side magic-byte checking to reject disguised executables and malware.
4
Auto-deletion Cloud Scheduler
Scheduled job deletes all uploaded files after 1 hour. Core privacy promise.
5
Client Encryption Web Crypto API
AES-256-GCM encryption in the browser before upload. Zero-knowledge storage.
6
Blockchain Proof Polygon + ethers.js
SHA-256 file hash written to Polygon for tamper-proof ownership verification.
Responsible Disclosure
If you discover a security vulnerability in Ziphay, please report it responsibly. We ask that you do not publicly disclose the issue until we have had a reasonable opportunity to address it.
To report a vulnerability, contact Abhay Donde via the Contact page and select "Bug Report" as the topic. Please include a detailed description of the vulnerability and steps to reproduce it.
We aim to respond to security reports within 72 hours and resolve critical issues within 7 days.