🔐 LinkVault - Secure Ephemeral File Sharing Service

LinkVault is a full-stack web application designed for secure, temporary file and text sharing. It features self-destructing links, password protection, view counting, and automated cleanup mechanisms. Built with a focus on security and privacy, it ensures that sensitive data does not persist longer than necessary.

🚀 Features

• Ephemeral Storage: Content automatically expires after a set time (30s to 1 Day) or specific view count.
• Security First: Optional password protection (bcrypt hashing) and strictly typed file validation.
• User Dashboard: Specialized dashboard for registered users to manage active uploads.
• Anonymous Usage: Guest users can upload without registration.
• Manual Kill-Switch: Unique deletion tokens allow users to instantly destroy content before expiration.
• Automated Cleanup: Background Cron jobs permanently remove expired files from the disk.

🛠️ Tech Stack

• Frontend: React.js (Vite), Tailwind CSS, Lucide Icons, Axios.
• Backend: Node.js, Express.js.
• Database: SQLite3 (Serverless, zero-configuration).
• Security: Bcrypt (hashing), JWT (Sessions), Multer (Stream handling), NanoID (URL-safe IDs).

⚙️ Setup Instructions

Prerequisites

• Node.js (v16 or higher)
• npm (Node Package Manager)

1. Clone the Repository

git clone https://github.com/yourusername/linkvault.git
cd linkvault

2. Backend Setup

The backend handles API requests, file storage, and database management.

cd server
npm install
# Start the server (Runs on Port 3000)
node index.js

Note: The SQLite database (database.sqlite) will be created automatically upon the first run.

3. Frontend Setup

The frontend is a React SPA (Single Page Application). Open a new terminal window.

cd client
npm install
# Start the development server (Runs on Port 5173)
npm run dev

4. Access the Application

Open your browser and navigate to: http://localhost:5173

📡 API Overview

Authentication

Method	Endpoint	Description
POST	/api/auth/register	Create a new user account.
POST	/api/auth/login	Authenticate and receive a JWT.

Core Functionality

Method	Endpoint	Description
POST	/api/upload	Upload file/text. Supports expiry, password, maxViews.
POST	/api/view/:id	Retrieve metadata. Increments view count. Checks password.
GET	/api/download/:id	Stream the file content to the client.
GET	/api/delete/:id/:token	Kill-Switch. Permanently deletes file using a secret token.

User Management

Method	Endpoint	Description
GET	/api/user/uploads	List all active uploads for the logged-in user.

📐 Design Decisions

1. SQLite for Data Persistence

Decision: Used SQLite instead of MongoDB or PostgreSQL.

Reason: The application requires relational mapping (Users <-> Files) but does not need the overhead of a dedicated database server. SQLite is file-based, making the project portable and easy to deploy (perfect for a resume portfolio).

2. "Two-Key" Deletion Architecture

Decision: Deletion requires a unique deleteToken separate from the file id.

Reason: Prevents unauthorized deletion. Even if an attacker guesses a file URL (/view/abc), they cannot delete it without the separate token (/delete/abc/xyz) generated at upload time.

3. Passive vs. Active Expiration

Decision: Implemented both request-time checks and background Cron jobs.

Reason:

• Active (Request-time): If a user clicks an expired link, the server denies access immediately (even if the file is still on disk).
• Passive (Cron): A background job runs every minute to physically delete files from the uploads/ folder, ensuring disk space is reclaimed.

4. Security Headers & Validation

Decision: Implemented no-store headers and server-side file extension validation.

Reason:

• Cache-Control: no-store ensures sensitive secrets are not saved in the browser's history or cache.
• Multer filters block executable files (.exe, .sh) to prevent remote code execution (RCE) attacks on the server.

⚠️ Assumptions & Limitations

• Local Storage: Files are stored on the local filesystem (/server/uploads). In a production cloud environment, this should be replaced with an S3 bucket (AWS) or Blob Storage.
• Scalability: SQLite has write-locking limitations. For high-concurrency enterprise use, the database should be migrated to PostgreSQL.
• Single Instance: The current architecture assumes a single server instance. Use of node-cron would need to be managed differently in a load-balanced cluster (e.g., using a dedicated worker service).
• HTTPS: This project is configured for HTTP (Localhost). Production deployment requires SSL/TLS encryption to securely transmit passwords and file contents.