MCP Security Score
Documentation

Network Security Checks

Network security checks identify unsafe configurations that could expose your MCP server to man-in-the-middle attacks or other network-based vulnerabilities.

network-disabled-tls

Severity: High

What It Detects

Disabled TLS/SSL certificate verification:

  • rejectUnauthorized: false in HTTPS options
  • NODE_TLS_REJECT_UNAUTHORIZED=0 environment variable
  • agent: new https.Agent({ rejectUnauthorized: false })

Why It's Dangerous

Disabling TLS verification:

  • Allows man-in-the-middle attacks
  • Enables attackers to intercept sensitive data
  • Removes protection against certificate spoofing
  • Often introduced "temporarily" and never fixed

Example Vulnerable Code

// Disabled certificate verification
const https = require('https');
const agent = new https.Agent({
  rejectUnauthorized: false  // DANGEROUS!
});
 
// Using fetch with disabled verification
const response = await fetch(url, {
  agent: new https.Agent({ rejectUnauthorized: false })  // DANGEROUS!
});
 
// Environment variable
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';  // DANGEROUS!

Safe Alternative

// Use proper certificates
const https = require('https');
const agent = new https.Agent({
  rejectUnauthorized: true,  // Default, but explicit is good
  ca: fs.readFileSync('ca-cert.pem')  // Custom CA if needed
});
 
// For development with self-signed certs
if (process.env.NODE_ENV === 'development') {
  // Only disable in dev, and log a warning
  console.warn('TLS verification disabled in development');
}
 
// Better: use proper dev certificates
// - mkcert for local development
// - Let's Encrypt for staging

network-hardcoded-ip

Severity: Medium

What It Detects

Hardcoded IP addresses:

  • Localhost variations (127.0.0.1, ::1)
  • Private IP ranges (RFC 1918):
    • 10.0.0.0/8
    • 172.16.0.0/12
    • 192.168.0.0/16
  • Other hardcoded IPs

Why It's Dangerous

Hardcoded IPs can:

  • Expose internal network topology
  • Break when infrastructure changes
  • Make code less portable
  • Indicate potential SSRF vulnerabilities if user-controlled

Example Vulnerable Code

// Hardcoded internal IP
const apiServer = 'http://192.168.1.100:3000/api';
 
// Hardcoded localhost (may not work in containers)
const cache = redis.createClient({
  host: '127.0.0.1',  // May be intentional but flagged for review
  port: 6379
});
 
// Database connection
const db = new Client({
  host: '10.0.0.50',  // Internal network IP
  port: 5432
});

Safe Alternative

// Use environment variables
const apiServer = process.env.API_SERVER_URL;
 
// Use service names (for containers/k8s)
const cache = redis.createClient({
  host: process.env.REDIS_HOST || 'redis',
  port: parseInt(process.env.REDIS_PORT || '6379')
});
 
// Configuration from environment
const db = new Client({
  host: process.env.DB_HOST,
  port: parseInt(process.env.DB_PORT || '5432')
});

network-hardcoded-url

Severity: Info

What It Detects

Hardcoded external URLs in code. This is informational only, flagging URLs for review rather than indicating a definite problem.

Why It's Flagged

Hardcoded URLs may:

  • Need updating when services change
  • Contain environment-specific endpoints
  • Indicate external dependencies
  • Sometimes contain sensitive paths

Example Flagged Code

// External API URLs
const API_BASE = 'https://api.example.com/v1';  // Flagged for review
 
// Third-party services
const response = await fetch('https://analytics.service.com/track');
 
// CDN URLs
const cdnUrl = 'https://cdn.mycompany.com/assets';

When This Is Fine

Many hardcoded URLs are intentional:

  • Public API endpoints
  • CDN resources
  • Well-known service URLs

When to Fix

Consider using environment variables if:

  • URL differs between environments (dev/staging/prod)
  • URL contains internal paths
  • URL might change in the future
// Configurable URLs
const API_BASE = process.env.API_BASE_URL || 'https://api.example.com/v1';
const CDN_URL = process.env.CDN_URL || 'https://cdn.mycompany.com';

Summary

| Check | Severity | Key Fix | |-------|----------|---------| | network-disabled-tls | High | Never disable TLS verification in production | | network-hardcoded-ip | Medium | Use environment variables or service discovery | | network-hardcoded-url | Info | Review and consider configuration |

Best Practices

1. Always Validate Certificates

// Production should always validate
if (process.env.NODE_ENV !== 'development') {
  if (tlsOptions.rejectUnauthorized === false) {
    throw new Error('TLS verification cannot be disabled in production');
  }
}

2. Use Service Discovery

In containerized environments:

  • Use service names instead of IPs
  • Let orchestration handle discovery
  • Use environment variables for configuration

3. Centralize Configuration

// config.js
export const config = {
  apiUrl: process.env.API_URL,
  redisHost: process.env.REDIS_HOST,
  dbHost: process.env.DB_HOST,
};

Next Steps