The MCP HTTP Bridge follows these core security principles:

1. Localhost-First: Designed for local operation, not public internet exposure
2. Authentication Required: API key validation enabled by default
3. Principle of Least Privilege: Dangerous tools disabled by default
4. Defense in Depth: Multiple layers of security controls
5. Transparent Logging: Structured logs for security monitoring

We take security seriously. If you discover a security vulnerability, please help us responsibly disclose it.

DO NOT open a public GitHub issue for security vulnerabilities.

Instead:

1. Email: security@namelycorp.com
2. Subject: [SECURITY] MCP HTTP Bridge - Brief Description
3. Include:
   • Description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Suggested fix (if any)
   • Your contact information

• Initial Response: Within 48 hours
• Status Update: Within 7 days
• Fix Timeline: Depends on severity
  • Critical: 1-7 days
  • High: 7-14 days
  • Medium: 14-30 days
  • Low: 30-90 days

We maintain a security acknowledgments section for responsible disclosure:

• Public credit (unless you prefer to remain anonymous)
• Recognition in CHANGELOG.md
• Potential bounty (at our discretion)

✅ Unauthorized Access

• API key authentication (required by default)
• Rate limiting (120 requests per 30 seconds)
• Non-root user execution (in Docker)

✅ Command Injection

• Strict command whitelisting for exec tool
• Input validation and sanitization
• Shell escaping for arguments

✅ Network Exposure

• Localhost binding by default (127.0.0.1)
• Configurable CORS restrictions
• No wildcard CORS allowed

✅ Information Disclosure

• Structured logging with secret redaction
• No stack traces in production responses
• Security headers via Helmet.js

❌ Physical Access to Host

• If attacker has local access, all bets are off
• Use disk encryption and access controls

❌ Compromised API Keys

• Rotate keys regularly
• Store securely (never commit to git)
• Use key management systems in production

❌ Social Engineering

• Train users on security practices
• Implement organizational policies

❌ DDoS Attacks

• Rate limiting provides basic protection only
• Use proper DDoS mitigation for internet-facing deployments

❌ Zero-Day Vulnerabilities in Dependencies

• Keep dependencies updated
• Monitor security advisories
• Use automated scanning tools

# .env file
HOST=127.0.0.1                    # Localhost only
PORT=3333                         # Unprivileged port
MCP_AUTH_MODE=required            # Authentication required
MCP_API_KEY=<32+ character key>   # Strong random key
MCP_CORS_ORIGINS=                 # CORS disabled
MCP_ENABLE_EXEC=false             # exec tool disabled

• MCP_AUTH_MODE=required
• Strong API key (32+ random characters)
• API keys stored in environment variables or secrets manager
• Regular key rotation (every 90 days)
• Different keys for each environment (dev/staging/prod)

• HOST=127.0.0.1 (never 0.0.0.0 without reverse proxy)
• Firewall rules blocking external access to PORT
• Reverse proxy with SSL/TLS for remote access
• CORS allowlist configured (if needed)
• VPN or SSH tunnel for remote management

• Non-root user (mcpusr) in container
• Remove NET_RAW/NET_ADMIN capabilities if not needed
• Read-only root filesystem (if possible)
• Resource limits configured (CPU, memory)
• Regular image updates for security patches

• MCP_ENABLE_EXEC=false (unless absolutely necessary)
• If exec enabled: strict whitelist (minimal set of commands)
• Never whitelist interpreters (sh, bash, python, node)
• Never whitelist destructive commands (rm, dd, mkfs)
• Never whitelist privilege escalation (sudo, su)

• Centralized logging configured
• Security event monitoring (auth failures, blocked commands)
• Alerting for suspicious patterns
• Regular log review
• Health check monitoring

• Automated dependency updates (Dependabot, Renovate)
• Regular security audits (npm audit)
• Subscribe to security advisories
• Patch critical vulnerabilities within 7 days
• Regular backups of configuration

# DO NOT DO THIS
HOST=0.0.0.0
MCP_AUTH_MODE=off

Why it's dangerous:

• Anyone on the internet can access your tools
• No authentication required
• Potential for abuse (scanning, DoS, data exfiltration)

Solution:

• Always use HOST=127.0.0.1
• Enable authentication (MCP_AUTH_MODE=required)
• Use reverse proxy with SSL/TLS for remote access

# DO NOT DO THIS
MCP_API_KEY=password123
MCP_API_KEY=admin
MCP_API_KEY=test

Why it's dangerous:

• Easily guessable
• Common in breach databases
• No protection against brute force

Solution:

# Generate strong keys
openssl rand -base64 32
# or
node -e "console.log(require('crypto').randomBytes(32).toString('base64'))"

# DO NOT DO THIS
MCP_EXEC_WHITELIST=bash,sh,python,node,sudo,curl,wget

Why it's dangerous:

• bash, sh, python, node can execute arbitrary code
• sudo allows privilege escalation
• Effectively allows unrestricted command execution

Solution:

# Be specific and minimal
MCP_EXEC_WHITELIST=ping,dig,nslookup,host

# For CI/CD, only what's needed
MCP_EXEC_WHITELIST=git,npm,docker

# DO NOT DO THIS
MCP_CORS_ORIGINS=*

Why it's dangerous:

• Any website can make requests
• Potential for CSRF attacks
• Credential theft via malicious sites

Solution:

# Specific origins only
MCP_CORS_ORIGINS=http://localhost:5678,http://127.0.0.1:5678

# DO NOT DO THIS
git add .env
git commit -m "Add config"
git push

Why it's dangerous:

• API keys exposed in git history
• Permanent record (even if deleted later)
• Public repositories expose to everyone

Solution:

# Add to .gitignore
echo ".env" >> .gitignore

# Never commit secrets
# Use environment variables or secrets managers

{
  "level": "security",
  "message": "Authentication failed",
  "path": "/rpc",
  "ip": "192.168.1.100"
}

Alert if: Multiple failures from same IP in short period

{
  "level": "security",
  "message": "Exec command blocked by whitelist",
  "command": "bash",
  "reason": "Command 'bash' not whitelisted"
}

Alert if: Attempts to execute dangerous commands

{
  "level": "security",
  "message": "CORS origin rejected",
  "origin": "http://malicious-site.com"
}

Alert if: Unknown origins attempting access

1. Authentication Success Rate

   • Target: > 99%
   • Alert: < 95% (potential brute force)

2. Tool Execution Errors

   • Target: < 1%
   • Alert: Sudden spike (potential attack)

3. Rate Limit Hits

   • Target: Rare
   • Alert: Multiple hits (potential DoS)

4. Container Restarts

   • Target: Near zero
   • Alert: Frequent restarts (potential crash loop)

1. Immediate Actions

   # Stop the service
   docker-compose down
   # or
   sudo systemctl stop mcp-bridge
   
   # Rotate all API keys
   export MCP_API_KEY="$(openssl rand -base64 32)"
   
   # Review logs
   docker-compose logs | grep -i "security\|error"

2. Investigation

   • Review authentication logs for unauthorized access
   • Check executed commands for suspicious activity
   • Examine network connections
   • Review file modifications

3. Containment

   • Isolate affected systems
   • Block suspicious IPs at firewall level
   • Revoke compromised credentials

4. Recovery

   • Apply security patches
   • Update all dependencies
   • Restore from clean backup if necessary
   • Implement additional monitoring

5. Post-Incident

   • Document the incident
   • Improve security controls
   • Update this document with lessons learned

Run this checklist quarterly or after major changes:

• API key strength verified (32+ characters, random)
• MCP_AUTH_MODE=required in production
• HOST=127.0.0.1 or behind authenticated reverse proxy
• CORS configured with specific origins (no wildcards)
• exec tool disabled or with minimal whitelist

• npm audit shows no critical/high vulnerabilities
• All dependencies up to date
• No known CVEs in base Docker image
• Automated update process in place

• API keys rotated within last 90 days
• No hardcoded secrets in code
• .env file not committed to git
• Proper file permissions on .env (600)

• Centralized logging configured
• Security alerts configured
• Log retention policy defined
• Regular log review process

• Running as non-root user
• Unnecessary capabilities removed
• Resource limits configured
• Health checks working
• No privileged containers

• Security Team: security@namelycorp.com
• On-Call: (Available to authorized personnel)
• Public Disclosure: After coordinated disclosure process

• OWASP Top 10
• CWE Top 25
• Docker Security Best Practices
• Node.js Security Best Practices

• v1.0.0 (2025-02-04): Initial security policy

Last Updated: 2025-02-04