# Hastebin Security Implementation

This document explains the security measures implemented in Hastebin, particularly focusing on HTTP security headers and their testing.

## Security Headers Overview

Hastebin implements several security headers to protect against common web vulnerabilities:

### Content Security Policy (CSP)
- **Purpose**: Prevents XSS attacks and other code injection by controlling which resources can be loaded
- **Implementation**: Restricts scripts to same-origin, uses nonces for inline scripts
- **Configuration**: Controlled via `HASTEBIN_ENABLE_CSP` environment variable
- **Default Policy**: 
  - `script-src 'self'` (only same-origin scripts)
  - Dynamic nonces for necessary inline scripts
  - `unsafe-hashes` for certain UI interactions

### Cross-Origin Isolation
- **Purpose**: Enables powerful features like SharedArrayBuffer while preventing side-channel attacks
- **Headers**:
  - `Cross-Origin-Embedder-Policy: require-corp`
  - `Cross-Origin-Resource-Policy: same-origin`
  - `Cross-Origin-Opener-Policy: same-origin`
- **Configuration**: Enabled via `HASTEBIN_ENABLE_CROSS_ORIGIN_ISOLATION`

### HTTP Strict Transport Security (HSTS)
- **Purpose**: Ensures all connections use HTTPS, preventing downgrade attacks
- **Implementation**: Long max-age to ensure persistent HTTPS usage
- **Configuration**: Controlled by `HASTEBIN_ENABLE_HSTS`

### Additional Security Headers
- `X-Content-Type-Options: nosniff`: Prevents MIME type sniffing
- `X-Frame-Options: DENY`: Prevents clickjacking attacks
- `X-XSS-Protection: 1; mode=block`: Additional XSS protection for older browsers
- `Referrer-Policy: strict-origin-when-cross-origin`: Controls referrer information
- `Permissions-Policy`: Restricts access to powerful features

## Testing Security Implementation

The security implementation is thoroughly tested through our test suite located in the `test` directory:

### Test Directory Structure
```
test/
├── core/
│   └── core_functionality_spec.js    # Core functionality tests
├── security/
│   ├── security_spec.js             # Main security test suite
│   └── security_shell_spec.sh       # Shell-based security tests
├── key_generators/                  # Key generator tests
└── document_handler_spec.js         # Document handler tests
```

### Running Tests

```bash
# Run all tests (unit + security)
npm test

# Run only core functionality tests
npm run test:core

# Run security tests
npm run test:security                # Run all security tests
npm run test:security:csp           # Test CSP configuration
npm run test:security:cors          # Test CORS settings
npm run test:security:combined      # Test combined security features
```

## Test Documentation

### Core Functionality Tests
- Located in `test/core/core_functionality_spec.js`
- Tests basic Hastebin operations
- Includes document creation, retrieval, and rate limiting tests
- Uses Mocha test framework

### Security Tests
- Main test suite in `test/security/security_spec.js`
- Shell-based tests in `test/security/security_shell_spec.sh`
- Covers all security headers and configurations
- Includes both automated and manual test cases

## Development Considerations

1. **Development Mode**:
   - CSP can be relaxed in development via `HASTEBIN_BYPASS_CSP_IN_DEV`
   - Headers are still present but may be less restrictive

2. **Production Deployment**:
   - All security headers enabled by default
   - CSP in strict mode
   - HSTS recommended for production

3. **Monitoring and Maintenance**:
   - Regular security header audits
   - Updates based on browser security requirements
   - Compatibility testing with security measures enabled

## Best Practices

1. **Always run security tests before deployment**
2. **Keep security headers enabled in production**
3. **Regularly update security configurations**
4. **Monitor for security header effectiveness**
5. **Test core functionality with security measures enabled**