> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plugged.in/llms.txt
> Use this file to discover all available pages before exploring further.
# Security Overview
> Comprehensive security features and best practices for Plugged.in
# Security Documentation
Plugged.in implements comprehensive security measures to protect your data and prevent various attack vectors. This document outlines our security features and best practices.
## Security Features
### 1. URL Validation and SSRF Prevention
The application implements comprehensive URL validation to prevent Server-Side Request Forgery (SSRF) attacks.
* Only allows requests to explicitly trusted domains
* Prevents requests to arbitrary external services
* Configurable per environment
**Blocks all private IPv4 ranges (RFC 1918):**
* 10.0.0.0/8
* 172.16.0.0/12
* 192.168.0.0/16
* 169.254.0.0/16 (link-local)
* 127.0.0.0/8 (loopback)
**Blocks IPv6 private/local addresses:**
* ::1 (loopback)
* fe80::/10 (link-local)
* fc00::/7 (unique local)
* ff00::/8 (multicast)
### 2. Protocol Enforcement
* Only allows HTTP and HTTPS protocols
* Blocks potentially dangerous protocols: `file://`, `ftp://`, `javascript:`, `data:`
### 3. Credential Protection
* Prevents URLs with embedded credentials (username:password@)
* Protects against credential leakage
* Automatic credential stripping in shared configurations
### 4. Special Character Protection
* Blocks null bytes in URLs
* Prevents directory traversal attempts
* Path normalization and validation
## Usage Guidelines
### For External APIs
```typescript theme={null}
import { validateExternalUrl } from '@/lib/url-validator';
// Validate before making request
const url = validateExternalUrl('https://api.github.com/repos/owner/repo');
const response = await fetch(url.toString());
```
### For Internal Registry APIs
```typescript theme={null}
import { validateInternalUrl } from '@/lib/url-validator';
// More restrictive validation for internal services
// Allows: registry.plugged.in, staging.plugged.in and their api subdomains
const url = validateInternalUrl('https://registry.plugged.in/v0/servers');
const response = await fetch(url.toString());
```
### For Development with Localhost
```typescript theme={null}
// Localhost is automatically allowed in development (NODE_ENV=development)
const url = validateExternalUrl('http://localhost:8000');
// Or explicitly enable localhost in any environment
const url = validateExternalUrl('http://localhost:8000', {
allowLocalhost: true
});
```
## Security Assumptions
### Trust Boundary
The allowed domains list defines our trust boundary. Only add domains that are:
* Under our control (registry.plugged.in, staging.plugged.in)
* Well-known, trusted third-party services (GitHub, npm, etc.)
* Required for application functionality
### Environment-based Security
* Strict domain allowlisting
* No localhost access
* Enhanced monitoring
* Localhost automatically allowed
* Relaxed restrictions for testing
* Debug logging enabled
* Staging domains always allowed
* Production-like security
* Testing environment
### Defense in Depth
URL validation is one layer of defense. Additional layers include:
* Rate limiting on API endpoints
* Authentication and authorization checks
* Input validation at multiple levels
* Output encoding to prevent XSS
### Fail Secure
When validation fails, the request is blocked. No fallback or bypass mechanisms.
## Testing
Comprehensive test coverage is provided in `tests/security/url-validator.test.ts`:
* SSRF prevention tests
* IPv4 and IPv6 validation
* Domain allowlisting
* Credential blocking
* Protocol validation
* Edge cases and attack vectors
Run security tests:
```bash theme={null}
pnpm test tests/security/url-validator.test.ts
```
## Monitoring and Logging
Consider implementing:
1. **Security Telemetry**: Log blocked requests for security monitoring
2. **Rate Limiting**: Limit validation failures per IP to prevent abuse
3. **Alerting**: Alert on unusual patterns of blocked requests
## Updating Allowed Domains
To add a new allowed domain:
Review the domain's trustworthiness and necessity
Add to `ALLOWED_DOMAINS` in `lib/url-validator.ts`
Document the reason for addition in code comments
Update tests to cover the new domain
Determine if it should be in `validateInternalUrl` allowed list
## Known Limitations
1. **DNS Rebinding**: URL validation happens before the request. DNS rebinding attacks that occur after validation are not prevented by this layer.
2. **Redirect Following**: The validator only checks the initial URL. Server-side redirects need additional handling.
3. **Time-of-Check vs Time-of-Use**: Domain resolution can change between validation and request execution.
## Incident Response
If a security issue is discovered:
1. Block the affected domain/IP immediately
2. Review logs for exploitation attempts
3. Update validation rules
4. Deploy fix with urgency
5. Document in security changelog
## Regular Security Reviews
* Review allowed domains quarterly
* Update blocked IP ranges as new private ranges are allocated
* Monitor for new SSRF techniques and update defenses
* Keep dependencies updated for security patches
## Additional Security Features
### Collective Best Practices Privacy (v3.1.0+)
Plugged.in's Collective Best Practices (CBP) system aggregates anonymized patterns from the community. All data undergoes a **three-stage anonymization pipeline** before entering the collective pool:
1. **Regex PII Removal**: Strips emails, API keys, UUIDs, file paths, IPs, JWTs, connection strings, and bearer tokens
2. **LLM Generalization**: AI removes usernames, project names, company names, and domain-specific details while preserving technical insights
3. **Post-Processing Re-Scan**: LLM output is re-scanned to catch any PII that leaked through generalization
Additional privacy guarantees:
* **HMAC-SHA256 Profile Hashing**: Profile identities are keyed-hashed — raw UUIDs never stored in the collective pool
* **k-Anonymity (k≥3)**: Patterns only become visible when 3+ independent profiles contribute the same insight
* **No Reverse Mapping**: It is impossible to trace a collective pattern back to any individual user
For full details on the anonymization pipeline, see [Data Anonymization & Collective Knowledge](/security/data-anonymization).
### End-to-End Encryption (v2.2.0+)
* All sensitive MCP server configuration data encrypted at rest
* AES-256-GCM encryption
* Per-profile encryption keys
* Automatic encryption/decryption
### Rate Limiting
* Auth endpoints: 5 requests per 15 minutes
* API endpoints: 60 requests per minute
* Public endpoints: 100 requests per minute
* AI document creation: 10 requests per hour
### Input Validation
* Zod validation schemas for all server actions
* Sanitization of HTML/Markdown content
* Path traversal protection
* Content length validation
### MCP Protocol Security
The MCP Proxy implements comprehensive protocol security measures:
* **Protocol Version Validation**: Only supported MCP protocol versions accepted (2024-11-05)
* **Header Validation**: Strict header format enforcement with Title-Case standardization
* **Authentication Isolation**: Lazy auth - discovery operations work without credentials
* **Error Code Sanitization**: Standardized JSON-RPC 2.0 error codes prevent information leakage
* **CORS Configuration**: Secure CORS headers with proper origin and header restrictions
* **Session Management**: Secure session handling with optional stateless mode
For detailed MCP security implementation, see [MCP Protocol Compliance](/mcp-proxy/protocol-compliance).
## Contact
For security concerns or vulnerability reports, please contact:
* Email: [security@plugged.in](mailto:security@plugged.in)
* GitHub Security Advisories: [Report a vulnerability](https://github.com/VeriTeknik/pluggedin-app/security/advisories/new)