veza/veza-backend-api/tests/security/README.md

# Security Tests - veza-backend-api

## Overview

This directory contains security tests to verify that the application is protected against common security vulnerabilities, including:

- SQL Injection attacks
- Cross-Site Scripting (XSS) attacks
- Command Injection attacks
- Input validation and sanitization

## Running Security Tests

### Prerequisites

Security tests require the `security` build tag to be enabled:

```bash
go test -tags=security ./tests/security/... -v
```

### Individual Test Suites

**SQL Injection Tests**:
```bash
go test -tags=security ./tests/security -run TestSQLInjection -v
```

**XSS Tests**:
```bash
go test -tags=security ./tests/security -run TestXSS -v
```

**Command Injection Tests**:
```bash
go test -tags=security ./tests/security -run TestCommandInjection -v
```

**Sanitization Utility Tests**:
```bash
go test -tags=security ./tests/security -run TestSanitizeInput -v
```

## Test Coverage

### SQL Injection Protection

Tests verify that:
- GORM uses parameterized queries (prevents SQL injection)
- User input in query parameters is safely handled
- Path parameters are validated and sanitized
- Database integrity is maintained even with malicious input

**Test Payloads**: 30+ SQL injection payloads including:
- `' OR '1'='1`
- `'; DROP TABLE users; --`
- `' UNION SELECT * FROM users--`
- And many more variations

### XSS Protection

Tests verify that:
- HTML/JavaScript payloads are sanitized or escaped
- Dangerous URL schemes (javascript:, data:, vbscript:) are removed
- Event handlers (onclick, onerror, etc.) are stripped
- Script tags and iframes are removed or escaped

**Test Payloads**: 50+ XSS payloads including:
- `<script>alert('XSS')</script>`
- `<img src=x onerror=alert('XSS')>`
- `javascript:alert('XSS')`
- And many more variations

### Command Injection Protection

Tests verify that:
- Shell command injection attempts are blocked
- Dangerous characters (;, |, &, &&, ||, `, $()) are sanitized
- System commands cannot be executed through user input

**Test Payloads**: 30+ command injection payloads including:
- `; ls`
- `| cat /etc/passwd`
- `` `rm -rf /` ``
- `$(whoami)`
- And many more variations

### Input Sanitization

Tests verify that the `utils.SanitizeInput()` function:
- Escapes HTML special characters
- Removes dangerous URL schemes
- Removes control characters
- Limits input length to prevent DoS

## Expected Results

All security tests should **PASS**. If any test fails:

1. **SQL Injection Test Failure**: Indicates that raw SQL queries may be vulnerable. Check for:
   - Raw SQL queries using string concatenation
   - Missing parameterization in database queries
   - Direct user input in SQL queries

2. **XSS Test Failure**: Indicates that user input is not properly sanitized. Check for:
   - Missing sanitization in handlers
   - Unescaped output in responses
   - Missing Content-Security-Policy headers

3. **Command Injection Test Failure**: Indicates that system commands may be executed. Check for:
   - Use of `os/exec` with user input
   - Shell command execution with user-controlled data
   - Missing input validation

## Integration with CI/CD

Add security tests to your CI/CD pipeline:

```yaml
# Example GitHub Actions
- name: Run security tests
  run: |
    go test -tags=security ./tests/security/... -v
```

## Best Practices

1. **Always use parameterized queries**: Never concatenate user input into SQL queries
2. **Sanitize all user input**: Use `utils.SanitizeInput()` or similar functions
3. **Validate input**: Use validators from `internal/validators` package
4. **Escape output**: When rendering user input, always escape HTML/JavaScript
5. **Use security headers**: Ensure `SecurityHeaders` middleware is applied

## Related Files

- `internal/utils/sanitizer.go` - Input sanitization utilities
- `internal/middleware/security_headers_test.go` - Security headers tests
- `internal/validators/` - Input validation validators

## Notes

- Security tests use in-memory SQLite database for isolation
- Tests do not require external dependencies
- All test payloads are safe and do not cause actual harm
- Tests verify protection at both application and database levels