@spaik/mcp-server-roi/database/SECURITY_README.md

MCP server for AI ROI prediction and tracking with Monte Carlo simulations

# Security Updates for MCP Server ROI

## Overview

This directory contains critical security updates to address vulnerabilities in the database schema and access patterns.

## Security Issues Addressed

### 1. **Overly Permissive Database Grants**
- **Issue**: The original schema granted INSERT, UPDATE, and DELETE permissions to the `anon` role
- **Risk**: Any unauthenticated user could modify or delete data
- **Fix**: Removed dangerous grants, implemented proper RLS policies

### 2. **Missing User Isolation**
- **Issue**: No user_id columns in tables
- **Risk**: Users could access and modify each other's data
- **Fix**: Added user_id columns to all tables with automatic triggers

### 3. **Direct Admin Client Export**
- **Issue**: supabaseAdmin was exported directly
- **Risk**: Potential for bypassing security controls
- **Fix**: Created a secure data access layer with specific functions

## Migration Steps

### 1. Apply the Security Migration

Run the migration file in your Supabase SQL editor:

```sql
-- Run the contents of 001_security_update.sql
```

### 2. Update Environment Variables

Ensure you have proper Supabase configuration:

```bash
SUPABASE_URL=your_project_url
SUPABASE_ANON_KEY=your_anon_key
SUPABASE_SERVICE_KEY=your_service_key  # Only for admin operations
```

### 3. Enable Supabase Auth

1. Go to your Supabase dashboard
2. Navigate to Authentication settings
3. Enable email/password or OAuth providers
4. Configure auth settings as needed

### 4. Update Application Code

The application now uses RLS policies. Ensure:
- Users are authenticated before accessing data
- The Supabase client includes auth context
- All queries respect user boundaries

## Security Model

### Row Level Security (RLS)

All tables now have RLS enabled with policies that:
- Allow users to see only their own data
- Automatically set user_id on insert
- Prevent cross-user data access
- Cascade permissions through foreign keys

### Data Access Patterns

```typescript
// User operations (with RLS)
const { data, error } = await supabase
  .from('projects')
  .select('*');  // Returns only user's projects

// System operations (admin only)
const stats = await dataAccess.getSystemStats();  // Anonymous statistics
```

### Authentication Flow

1. User authenticates with Supabase Auth
2. Auth token included in requests
3. RLS policies check auth.uid()
4. Data filtered automatically

## Testing Security

### 1. Test RLS Policies

```sql
-- Test as different users
SET request.jwt.claims.sub = 'user-id-1';
SELECT * FROM projects;  -- Should only see user-id-1's projects

SET request.jwt.claims.sub = 'user-id-2';
SELECT * FROM projects;  -- Should only see user-id-2's projects
```

### 2. Test Permission Denial

```sql
-- Test unauthorized access
SET request.jwt.claims.sub = 'user-id-1';
UPDATE projects SET client_name = 'Hacked' 
WHERE user_id = 'user-id-2';  -- Should fail
```

## Best Practices

1. **Never disable RLS** in production
2. **Always use the public client** for user operations
3. **Limit admin operations** to specific, audited functions
4. **Log all admin actions** for audit trails
5. **Regularly review** RLS policies

## Rollback Plan

If issues arise:

1. Temporarily disable RLS (emergency only):
```sql
ALTER TABLE projects DISABLE ROW LEVEL SECURITY;
-- Repeat for other tables
```

2. Restore old permissions (not recommended):
```sql
-- Emergency grants (remove ASAP)
GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA public TO anon;
```

3. Debug and fix issues, then re-enable security

## Monitoring

Monitor for security issues:
- Failed authentication attempts
- RLS policy violations
- Unusual data access patterns
- Admin operation usage

## Support

For security questions or concerns:
- Review Supabase RLS documentation
- Check application logs for errors
- Test in development first
- Use Supabase dashboard for debugging