Uber Backend - Security and Privacy
Authentication and Authorization
1. User Authentication
Multi-Factor Authentication (MFA):
Primary Authentication:
- Phone number verification (SMS OTP)
- Email verification
- Social login (Google, Facebook, Apple)
Secondary Authentication:
- Biometric (Face ID, Touch ID)
- PIN code
- Security questions
Session Management:
- JWT tokens with 1-hour expiration
- Refresh tokens with 30-day expiration
- Device fingerprinting
- Automatic logout after 30 days of inactivityImplementation:
Login Flow:
1. User enters phone number
2. Server sends 6-digit OTP via SMS
3. User enters OTP
4. Server validates OTP
5. Generate JWT access token + refresh token
6. Store session in Redis with device info
7. Return tokens to client
Token Structure:
{
"user_id": "uuid",
"user_type": "RIDER",
"device_id": "device_uuid",
"issued_at": 1704715200,
"expires_at": 1704718800,
"permissions": ["ride:request", "payment:view"]
}
Security Measures:
- Rate limit OTP requests (5 per hour per phone)
- OTP expires after 5 minutes
- Maximum 3 OTP attempts
- Block phone number after 10 failed attempts
- Detect and block virtual phone numbers2. Authorization and Access Control
Role-Based Access Control (RBAC):
Roles:
- RIDER: Request rides, view history, manage payments
- DRIVER: Accept rides, update location, view earnings
- ADMIN: Manage users, view analytics, configure system
- SUPPORT: View trips, issue refunds, resolve disputes
Permissions:
- ride:request, ride:cancel, ride:view
- driver:accept, driver:location, driver:earnings
- payment:process, payment:refund
- admin:users, admin:analytics, admin:config
Implementation:
- JWT contains user role and permissions
- API Gateway validates permissions before routing
- Service-level authorization checks
- Audit logging of all permission checksAPI Authorization:
Authorization Header:
Authorization: Bearer {JWT_TOKEN}
Permission Check:
1. Extract JWT from Authorization header
2. Validate JWT signature and expiration
3. Extract user_id and permissions
4. Check if user has required permission
5. Allow or deny request
Example:
POST /v1/rides/request
Required Permission: ride:request
User Permissions: [ride:request, ride:cancel, payment:view]
Result: ALLOWED
POST /v1/admin/users
Required Permission: admin:users
User Permissions: [ride:request, ride:cancel]
Result: DENIED (403 Forbidden)Data Encryption
1. Encryption at Rest
Database Encryption:
PostgreSQL:
- Transparent Data Encryption (TDE)
- AES-256 encryption for all data at rest
- Encrypted backups
- Key rotation every 90 days
Sensitive Fields (Additional Encryption):
- Payment card numbers: Tokenized + encrypted
- SSN/Tax IDs: AES-256 with separate key
- Driver license numbers: AES-256 with separate key
- Phone numbers: Hashed for lookup, encrypted for storage
Implementation:
-- Encrypted column example
CREATE TABLE payment_methods (
payment_method_id UUID PRIMARY KEY,
user_id UUID,
card_token VARCHAR(255), -- Tokenized by Stripe
card_encrypted BYTEA, -- Encrypted card details
encryption_key_id VARCHAR(50)
);
-- Encryption function
SELECT pgp_sym_encrypt(
'sensitive_data',
encryption_key,
'cipher-algo=aes256'
);File Storage Encryption:
S3 Encryption:
- Server-side encryption (SSE-S3)
- AES-256 encryption
- Encrypted in transit (TLS)
- Encrypted at rest
Profile Images:
- Encrypted with S3 SSE
- Signed URLs for access (1-hour expiration)
- CloudFront for delivery with HTTPS
Trip Receipts:
- Encrypted PDFs
- Access controlled by user authentication
- Automatic deletion after 7 years2. Encryption in Transit
TLS/SSL Configuration:
TLS Version: TLS 1.3 (minimum TLS 1.2)
Cipher Suites:
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_GCM_SHA256
Certificate Management:
- Let's Encrypt for automatic renewal
- Certificate pinning in mobile apps
- HSTS (HTTP Strict Transport Security)
- Certificate transparency monitoring
API Gateway Configuration:
server {
listen 443 ssl http2;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
add_header Strict-Transport-Security "max-age=31536000" always;
}End-to-End Encryption (E2E):
Use Cases:
- Driver-rider messaging
- Support chat conversations
- Sensitive document uploads
Implementation:
1. Generate key pair for each user
2. Exchange public keys
3. Encrypt messages with recipient's public key
4. Decrypt with recipient's private key
5. Server cannot read message content
Signal Protocol:
- Perfect forward secrecy
- Deniable authentication
- Asynchronous messaging supportPCI DSS Compliance
Payment Card Industry Data Security Standard
Compliance Requirements:
Level 1 Compliance (>6M transactions/year):
- Annual on-site security assessment
- Quarterly network scans
- Maintain secure network
- Protect cardholder data
- Maintain vulnerability management program
- Implement strong access control measures
- Regularly monitor and test networks
- Maintain information security policy
Implementation:
1. Tokenization:
- Never store actual card numbers
- Use Stripe/Braintree tokens
- Tokens stored in separate database
2. Network Segmentation:
- Payment services in isolated network
- Firewall rules restrict access
- No direct internet access
3. Access Control:
- Minimum necessary access
- Multi-factor authentication
- Audit logging of all access
4. Monitoring:
- Real-time fraud detection
- Anomaly detection
- Security event logging
- Quarterly vulnerability scansPayment Data Handling:
Card Data Flow:
1. User enters card in mobile app
2. App sends directly to Stripe (not Uber servers)
3. Stripe returns token
4. Uber stores token (not card number)
5. For payments, Uber sends token to Stripe
6. Stripe processes payment
Data Storage:
✓ Store: Token, last 4 digits, expiry month/year, brand
✗ Never Store: Full card number, CVV, PIN
Audit Trail:
- Log all payment attempts
- Log all token usage
- Log all refunds
- Retain logs for 7 yearsPrivacy and Data Protection
1. GDPR Compliance (Europe)
User Rights:
Right to Access:
- API endpoint: GET /v1/users/me/data
- Returns all user data in JSON format
- Includes trips, payments, ratings, location history
- Response within 30 days
Right to Erasure (Right to be Forgotten):
- API endpoint: DELETE /v1/users/me
- Anonymize user data (keep for analytics)
- Delete personal identifiers
- Retain financial data for 7 years (legal requirement)
- Complete deletion within 30 days
Right to Data Portability:
- Export user data in machine-readable format (JSON, CSV)
- Include all trips, payments, preferences
- Provide download link valid for 7 days
Right to Rectification:
- Allow users to update personal information
- Verify changes with email/SMS confirmation
- Audit trail of all changesData Minimization:
Collect Only Necessary Data:
- Location: Only during active trip
- Contacts: Only if user enables sharing
- Photos: Only profile picture (optional)
- Payment: Only necessary for transactions
Data Retention:
- Active user data: Indefinite
- Inactive user data (>2 years): Anonymize
- Trip data: 2 years, then archive
- Location data: 90 days, then delete
- Logs: 1 year, then delete
- Financial data: 7 years (legal requirement)2. CCPA Compliance (California)
Consumer Rights:
Right to Know:
- Disclose categories of personal information collected
- Disclose sources of information
- Disclose business purpose for collection
- Disclose third parties with whom data is shared
Right to Delete:
- Delete personal information upon request
- Exceptions for legal obligations
- Confirm deletion within 45 days
Right to Opt-Out:
- Opt-out of data sale (Uber doesn't sell data)
- Opt-out of targeted advertising
- Opt-out of location tracking (except during trips)
Do Not Sell My Personal Information:
- Prominent link in app and website
- Easy opt-out process
- Respect opt-out for 12 months3. Location Privacy
Location Data Handling:
Collection:
- Collect location only when app is active
- Request permission before collection
- Explain why location is needed
- Allow users to deny location access
Storage:
- Store location data for 90 days
- Anonymize after 90 days
- Aggregate for analytics
- Delete on user request
Sharing:
- Share with driver only during active trip
- Share with rider only during active trip
- Never share with third parties
- Never use for advertising
User Controls:
- Enable/disable location tracking
- View location history
- Delete location history
- Download location dataFraud Detection and Prevention
1. Payment Fraud Detection
Real-time Fraud Scoring:
Fraud Signals:
- New payment method used
- High-value transaction
- Unusual trip pattern
- Mismatched billing address
- VPN/proxy usage
- Device fingerprint mismatch
- Velocity checks (multiple cards in short time)
ML Model:
- Features: 100+ signals
- Model: Gradient Boosting (XGBoost)
- Training: Daily on last 90 days of data
- Inference: <50ms per transaction
Fraud Score:
- 0-30: Low risk (auto-approve)
- 31-70: Medium risk (additional verification)
- 71-100: High risk (block transaction)
Actions:
- Low risk: Process payment
- Medium risk: Require 3D Secure verification
- High risk: Block payment, flag accountFraud Prevention Measures:
Payment Verification:
- 3D Secure (3DS) for high-risk transactions
- CVV verification for all card payments
- Address verification (AVS)
- Device fingerprinting
- Behavioral biometrics
Account Monitoring:
- Detect account takeover attempts
- Monitor for unusual activity
- Flag rapid payment method changes
- Detect stolen credit cards
Chargeback Management:
- Automated dispute response
- Evidence collection (GPS, receipts)
- Chargeback rate monitoring
- Proactive refunds for legitimate issues2. Trip Fraud Detection
Fraudulent Trip Patterns:
Detection Signals:
- GPS spoofing (impossible speeds, teleportation)
- Route manipulation (unnecessary detours)
- Fake trips (driver and rider collude)
- Rating manipulation (fake 5-star ratings)
- Promo code abuse (multiple accounts)
ML Model:
- Anomaly detection on trip patterns
- Graph analysis for collusion detection
- Time-series analysis for GPS data
- Natural language processing for reviews
Actions:
- Flag suspicious trips for review
- Suspend accounts pending investigation
- Refund riders for fraudulent trips
- Terminate drivers for repeated fraudSecurity Monitoring and Incident Response
1. Security Monitoring
SIEM (Security Information and Event Management):
Log Collection:
- Application logs
- Database audit logs
- Network traffic logs
- Authentication logs
- API access logs
Security Events:
- Failed login attempts
- Privilege escalation attempts
- Unusual data access patterns
- SQL injection attempts
- DDoS attacks
Alerting:
- Real-time alerts for critical events
- Slack/PagerDuty integration
- Automated response for known threats
- Escalation to security teamVulnerability Management:
Scanning:
- Weekly vulnerability scans
- Dependency scanning (Snyk, Dependabot)
- Container image scanning
- Infrastructure as Code scanning
Patching:
- Critical vulnerabilities: 24 hours
- High vulnerabilities: 7 days
- Medium vulnerabilities: 30 days
- Low vulnerabilities: 90 days
Penetration Testing:
- Annual third-party penetration test
- Quarterly internal penetration test
- Bug bounty program
- Responsible disclosure policy2. Incident Response
Incident Response Plan:
Phases:
1. Detection: Identify security incident
2. Containment: Isolate affected systems
3. Eradication: Remove threat
4. Recovery: Restore normal operations
5. Lessons Learned: Post-mortem analysis
Incident Severity:
- SEV1: Data breach, system compromise
- SEV2: Attempted breach, DDoS attack
- SEV3: Vulnerability discovered
- SEV4: Policy violation
Response Team:
- Security Lead
- Engineering Lead
- Legal Counsel
- PR/Communications
- Customer Support
Communication:
- Internal: Slack, email, incident channel
- External: Status page, email to affected users
- Regulatory: Report within 72 hours (GDPR)Data Breach Response:
Immediate Actions:
1. Identify scope of breach
2. Contain breach (isolate systems)
3. Preserve evidence
4. Notify security team
5. Assess impact
Notification:
- Affected users: Within 72 hours
- Regulators: Within 72 hours (GDPR)
- Law enforcement: If criminal activity
- Credit bureaus: If SSN/financial data
Remediation:
- Force password reset for affected users
- Revoke compromised tokens
- Patch vulnerability
- Enhance monitoring
- Conduct post-mortemSecure Development Practices
1. Secure SDLC
Development Process:
Code Review:
- Mandatory peer review for all code
- Security-focused review for sensitive code
- Automated security scanning (SonarQube)
- OWASP Top 10 checklist
Testing:
- Unit tests with security test cases
- Integration tests for auth/authz
- Penetration testing before release
- Fuzz testing for input validation
Deployment:
- Automated security checks in CI/CD
- Container image scanning
- Infrastructure as Code security scanning
- Gradual rollout with monitoringSecurity Training:
Developer Training:
- Annual security awareness training
- OWASP Top 10 training
- Secure coding practices
- Incident response procedures
Certifications:
- Certified Secure Software Lifecycle Professional (CSSLP)
- Certified Information Systems Security Professional (CISSP)
- AWS Certified Security SpecialtyThis comprehensive security and privacy framework ensures Uber protects user data, complies with regulations, and maintains trust while operating at global scale.