Security Considerations

​

Security Model Overview

• Session isolation: Each session is identified by a unique 5-character code
• No authentication: Access is controlled solely by knowing the session code
• Public database access: Uses Supabase anonymous key for client-side operations
• HTTPS encryption: All data transmission uses TLS encryption
• Client-side compression: Images compressed locally before upload

​

Session Code Security

​

How Session Codes Work

const characters = "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
let newCode = "";
for (let i = 0; i < 5; i++) {
  newCode += characters.charAt(Math.floor(Math.random() * characters.length));
}

​

Code Space and Collision Risk

• Character set: 36 characters (26 letters + 10 digits)
• Code length: 5 characters
• Total possible codes: 36^5 = 60,466,176 combinations

• With 1,000 active sessions: ~0.0017% chance of collision
• With 10,000 active sessions: ~0.017% chance of collision
• With 100,000 active sessions: ~0.17% chance of collision

​

Session Code Best Practices

​

Sensitive Content Feature

​

How It Works

​

Sensitive Flag Implementation

export const convertLinksToAnchor = (text, item) => {
  if(item.sensitive) {
    // replace it with ******
    return "**********************";
  }
  // ... process links normally
};

​

When to Use Sensitive Flag

• Passwords and credentials
• API keys and tokens
• Personal identification numbers
• Private addresses or phone numbers
• Financial information
• Any content you don’t want visible on screen

• End-to-end encryption
• Password managers
• Secure credential storage
• Compliance with data protection regulations

​

Data Encryption in Transit

​

HTTPS/TLS Encryption

const SUPABASE_URL = import.meta.env.VITE_SUPABASE_URL; // https://...supabase.co
const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY);

• HTTP API requests (POST, GET, DELETE)
• WebSocket connections (Real-time subscriptions)
• File uploads to storage
• Database queries

• Protocol: TLS 1.2 or higher
• Managed by Supabase infrastructure
• Same level of encryption as banking sites

​

What’s NOT Encrypted at Rest

• Session codes in sessions table
• Clipboard text content in clipboard table
• File metadata (names, paths, types)
• Uploaded files in storage bucket
• Timestamps and session associations

• Use sensitive flag for private content
• Delete content after use
• Don’t store highly sensitive data long-term
• Consider self-hosting for full control

​

Supabase Security

​

Anonymous Key Usage

const SUPABASE_ANON_KEY = import.meta.env.VITE_SUPABASE_ANON_KEY;

• Key is visible in client-side code (by design)
• Same key for all users
• Access control via Row Level Security (RLS) policies
• No per-user authentication

​

Row Level Security (RLS)

-- Example RLS policy
CREATE POLICY "Allow all" ON clipboard FOR ALL USING (true);

• Permissive policies allowing all operations
• Session isolation enforced at application level
• No user authentication required

• Anyone can query the database
• Session codes provide only logical separation
• Physical security depends on code secrecy

​

Storage Bucket Security

const { data, error } = await supabase.storage
  .from("clipboard")
  .upload(`files/${random + file.name}`, file);

• Name: clipboard
• Access: Public (required for direct file access)
• Max file size: 10MB (enforced at application level)

• All uploaded files are publicly accessible
• File URLs are predictable (bucket/files/[prefix][filename])
• No automatic expiration (files persist until deleted)
• 3-character random prefix prevents some collisions

​

Best Practices for Sensitive Data

​

What to Store in ClipSync

• Public links and URLs
• Non-sensitive text snippets
• Code samples (without credentials)
• General notes and reminders
• Public file transfers
• Temporary collaboration content

• Passwords (use sensitive flag, delete after use)
• API keys (use sensitive flag, rotate keys regularly)
• Personal information (minimize retention time)
• Work documents (check company policies)
• Files with metadata (EXIF data, document properties)

• Credit card numbers
• Social security numbers
• Private keys or certificates
• Highly confidential business data
• Medical records
• Data subject to regulatory compliance (HIPAA, GDPR, etc.)

​

Data Retention Strategy

​

Secure Workflows

​

Password Transfer Workflow

​

File Transfer Workflow

​

Session Isolation

​

How Isolation Works

const { data, error } = await supabase
  .from("clipboard")
  .select("*")
  .eq("session_code", sessionCode) // Filter by session
  .order("created_at", { ascending: false });

• Each session only sees its own clipboard items
• Real-time updates filtered by session code
• Database queries restricted to current session
• File uploads tagged with session association

if (payload.new.session_code === sessionCode && payload.eventType === "INSERT") {
  setHistory((prev) => [payload.new, ...prev]);
}

​

Cross-Session Security

• Not through the application UI
• Theoretically possible via direct database queries
• Session codes must be known or guessed

1. Session codes are random and unpredictable
2. No session listing or discovery feature
3. Application enforces session filtering
4. Real-time subscriptions filtered by session

​

Security Limitations

​

Known Limitations

​

Technical Limitations

1. No end-to-end encryption: Data readable by database administrators
2. No user authentication: Access control via session codes only
3. No access logs: Can’t track who accessed what content
4. No permission system: All session members have full access
5. No session expiration: Sessions persist indefinitely
6. Public storage: Uploaded files accessible via URL

​

Threat Model

• Casual browsing by non-participants
• Accidental data exposure in session history (via sensitive flag)
• Man-in-the-middle attacks (via HTTPS)
• Network eavesdropping (via TLS encryption)

• Intentional session code guessing (low probability)
• Database administrator access
• Compromised Supabase credentials
• Client-side attacks (XSS, if vulnerabilities exist)
• Screen capture or shoulder surfing
• Shared computer access (session stored in browser)

​

Privacy Considerations

​

Data Storage Duration

• No automatic expiration
• Sessions remain active indefinitely
• Files stored permanently until deleted
• No data retention policies by default

​

Data Visibility

1. You and session participants: Via application UI
2. Database administrators: Via direct database access
3. Supabase staff: In rare cases for support or maintenance
4. Backup systems: Data included in database backups
5. Potential attackers: If session code is compromised

​

Metadata Leakage

• File names (visible in storage URLs)
• Upload timestamps
• Session creation times
• Number of items in session
• File sizes and types

​

Compliance Considerations

​

GDPR and Data Protection

• Right to deletion: Implement via delete all feature
• Data portability: No export feature currently
• Purpose limitation: Use separate sessions for different purposes
• Data minimization: Delete content after use
• Storage limitation: No automatic expiration

​

HIPAA and Healthcare Data

• No audit controls
• No user authentication
• No access controls
• No encryption at rest
• No business associate agreement (BAA)

​

Recommendations for Enhanced Security

​

1. Self-Host ClipSync

• Full control over data storage
• Implement custom security policies
• Add authentication layer
• Enable encryption at rest
• Control backup and retention

​

2. Implement Authentication

// Add user authentication before session access
const { user, error } = await supabase.auth.signIn({
  email: userEmail,
  password: userPassword
});

​

3. Add End-to-End Encryption

// Pseudo-code example
const encrypted = encrypt(content, sessionCode);
await supabase.from("clipboard").insert([{ content: encrypted }]);

​

4. Implement Session Expiration

DELETE FROM clipboard 
WHERE created_at < NOW() - INTERVAL '24 hours';

​

5. Add Row Level Security

CREATE POLICY "Users see only their sessions" 
ON clipboard FOR SELECT 
USING (auth.uid() = user_id);

​

Next Steps