← Back to ColdFusion Administrator Reference

Debugging & Logging - IP Addresses

Configure IP filtering for debug output and secure debugging access

Last updated: October 27, 20255 min read

Overview

The IP Addresses page in ColdFusion Administrator provides centralized configuration for restricting debug output and debugging features to specific IP addresses. This critical security feature ensures that sensitive debugging information is only visible to authorized developers, not to end users or potential attackers. IP filtering enables safe debugging in staging and even production environments when emergency troubleshooting is required.

Without IP filtering, enabling debug output would expose application internals, database queries, variable contents, and file paths to all users. IP filtering creates a secure boundary where only requests from approved IP addresses receive debug output, while all other users see the application normally without any debugging information.

IP Address Configuration

Configure which IP addresses can receive debug output and debugging information.

Adding IP Addresses

FormatIndividual IP addresses entered one per line or comma-separated

Single IP192.168.1.100

IPv4Standard dotted decimal notation

IPv6Full IPv6 address format (if supported by CF version)

Localhost127.0.0.1 for server-based debugging

Best Practice: Always test from specified IP to verify access after adding it to the list.

Wildcard Patterns

Asterisk WildcardUse * for range matching

Class C Network192.168.1.* (all IPs from .0 to .255)

Class B Network192.168.*.* (entire 192.168.0.0/16 range)

Partial Match10.0.* (matches 10.0.0.0 through 10.0.255.255)

Security Warning: Overly broad wildcards reduce security. Use specific IPs or small ranges when possible.

CIDR Notation

Format192.168.1.0/24 (network/prefix length)

SupportSome CF versions support CIDR notation

/24Class C network (256 addresses)

/16Class B network (65,536 addresses)

/32Single IP address

Advantage: More precise than wildcard for specific ranges and easier to document network boundaries.

Removing IP Addresses

InterfaceSelect IP and click remove/delete button

Immediate EffectTakes effect immediately (no restart needed)

CleanupRemove departed developers' IPs promptly

Best Practice: Regularly review and clean IP list to maintain security and remove outdated entries.

IP Detection and Challenges

Understanding how ColdFusion detects client IP addresses in different network configurations.

Direct Connections

Scenario: User connects directly to CF server
IP Source: CGI.REMOTE_ADDR contains actual client IP
Reliability: Most reliable scenario for IP filtering

CF compares CGI.REMOTE_ADDR to IP list for matching

Proxy Servers

Challenge: Proxy IP seen by CF, not client IP
Solution: X-Forwarded-For header passes original IP
Configuration: CF may need config to use X-Forwarded-For

Verify proxy sets this header reliably. Alternative: add proxy IP to allowed list (less secure)

Load Balancers

Issue: Load balancer IP appears as source
Solution: Configure load balancer to pass client IP
Headers: X-Forwarded-For, X-Real-IP, or custom headers

Use cfdump var="#CGI#" to see what CF detects

VPN Connections

Challenge: VPN exit node IP may change
Solution: Add all possible VPN exit node IPs
Alternative: Use wildcard or CIDR for VPN IP range

Corporate VPN usually has stable IP range. Test your IP while connected to VPN.

Dynamic IPs (Home/Mobile)

Problem: Developer IP changes frequently
Solution 1: Use broader ISP IP range (check WHOIS)
Solution 2: Use VPN with static IP

Security trade-off: broader range is less secure. Consider authentication instead of IP filtering.

Security Considerations

Information Disclosure Prevention

Primary PurposePrevent debug info exposure to unauthorized users

Sensitive DataDatabase queries, passwords, file paths, business logic

Attack SurfaceDebug output reveals attack vectors

CompliancePCI, HIPAA, GDPR prohibit exposing sensitive data

Security Critical: IP filtering is one layer, not sole protection. Always disable debug output in production unless absolutely necessary.

Security Best Practices

Essential Security Guidelines:

Use specific IP addresses, not broad ranges
Regularly audit and remove outdated IPs
Document who owns each IP address
Monitor for unauthorized access attempts
Use VPN for remote developers when possible
Never allow 0.0.0.0 or *.*.*.* (matches everything)
Test IP filtering from both allowed and disallowed IPs
Log IP filtering decisions for audit trail

Production Debugging

When to EnableEmergency only - Enable production debug output only for emergencies

Strict FilteringSingle admin IP, no wildcards

Time LimitedEnable only during active debugging

Minimal ScopeEnable only necessary debug categories

Critical: Log when and why production debugging was enabled. Follow change management procedures.

Common Mistakes

Avoid These Common Errors:

Adding 0.0.0.0: May match all IPs or no IPs depending on implementation
Using *.*.*.*: Defeats entire purpose of IP filtering
Not testing from disallowed IP: May not realize filtering is ineffective
Forgetting to update after IP changes: Legitimate developers blocked
Overly broad wildcards: 10.*.*.* exposes debug to millions of IPs
Not documenting IPs: Unclear who each IP belongs to

Testing IP Filtering

Verification Process

Step-by-Step Testing:

Determine your current IP (use whatismyip.com or similar)
Add your IP to allowed list in CF Administrator
Enable debug output in Debug Output Settings
Access application from your IP - debug output should appear
Access from different IP or use proxy - no debug output should appear
Check CF logs for IP filtering messages

Test IP Detection Script

Use this script to see what IP ColdFusion detects for your requests:

🔍 ip-test.cfm - Verify IP Detection

<!--- /admin/ip-test.cfm --->
<cfscript>
  // Display all relevant IP-related CGI variables
  ipInfo = {
    "REMOTE_ADDR": cgi.remote_addr,
    "HTTP_X_FORWARDED_FOR": cgi.http_x_forwarded_for ?: "Not set",
    "HTTP_X_REAL_IP": cgi.http_x_real_ip ?: "Not set",
    "HTTP_CLIENT_IP": cgi.http_client_ip ?: "Not set"
  };
</cfscript>

<!DOCTYPE html>
<html>
<head>
  <title>IP Detection Test</title>
  <style>
    body { font-family: Arial, sans-serif; padding: 20px; }
    table { border-collapse: collapse; width: 100%; max-width: 600px; }
    th, td { border: 1px solid #ddd; padding: 12px; text-align: left; }
    th { background-color: #f0f0f0; font-weight: bold; }
  </style>
</head>
<body>
  <h1>IP Detection Test</h1>
  <p>This shows what IP information ColdFusion can see:</p>

  <table>
    <tr>
      <th>Variable</th>
      <th>Value</th>
    </tr>
    <cfloop collection="#ipInfo#" item="key">
      <tr>
        <td><cfoutput>#key#</cfoutput></td>
        <td><cfoutput>#ipInfo[key]#</cfoutput></td>
      </tr>
    </cfloop>
  </table>

  <h2>Recommendations</h2>
  <ul>
    <li>Add <strong><cfoutput>#cgi.remote_addr#</cfoutput></strong> to IP whitelist</li>
    <cfif len(cgi.http_x_forwarded_for)>
      <li>Note: X-Forwarded-For detected - you may be behind a proxy/load balancer</li>
    </cfif>
  </ul>
</body>
</html>

<!--- /admin/ip-test.cfm --->
<cfset ipInfo = {
  "REMOTE_ADDR" = cgi.remote_addr,
  "HTTP_X_FORWARDED_FOR" = len(cgi.http_x_forwarded_for) ? cgi.http_x_forwarded_for : "Not set",
  "HTTP_X_REAL_IP" = len(cgi.http_x_real_ip) ? cgi.http_x_real_ip : "Not set",
  "HTTP_CLIENT_IP" = len(cgi.http_client_ip) ? cgi.http_client_ip : "Not set"
}>

<!DOCTYPE html>
<html>
<head>
  <title>IP Detection Test</title>
  <style>
    body { font-family: Arial, sans-serif; padding: 20px; }
    table { border-collapse: collapse; width: 100%; max-width: 600px; }
    th, td { border: 1px solid #ddd; padding: 12px; text-align: left; }
    th { background-color: #f0f0f0; font-weight: bold; }
  </style>
</head>
<body>
  <h1>IP Detection Test</h1>
  <p>This shows what IP information ColdFusion can see:</p>

  <table>
    <tr>
      <th>Variable</th>
      <th>Value</th>
    </tr>
    <cfloop collection="#ipInfo#" item="key">
      <tr>
        <td><cfoutput>#key#</cfoutput></td>
        <td><cfoutput>#ipInfo[key]#</cfoutput></td>
      </tr>
    </cfloop>
  </table>

  <h2>Recommendations</h2>
  <ul>
    <li>Add <strong><cfoutput>#cgi.remote_addr#</cfoutput></strong> to IP whitelist</li>
    <cfif len(cgi.http_x_forwarded_for)>
      <li>Note: X-Forwarded-For detected - you may be behind a proxy/load balancer</li>
    </cfif>
  </ul>
</body>
</html>

How to Use:

Create this file in your webroot (e.g., /admin/ip-test.cfm)
Access it from your browser
Note the REMOTE_ADDR value - this is what CF uses for IP filtering
Add that IP to the CF Administrator IP whitelist

Troubleshooting Access Issues

Issue: Debug output not appearing even though IP is added

Solutions:

Verify IP actually matches allowed list using the test script above
Check debug output is enabled in Debug Output Settings
Confirm IP list has at least one entry
Check for proxy/load balancer issues (X-Forwarded-For configuration)
Test exact IP instead of wildcard first
Verify IPv4 vs IPv6 - ensure using correct IP version
Some CF versions may require restart after IP changes (rare)

Multi-Environment Testing

Environment-Specific Considerations:

Test IP filtering in each environment (dev, staging, production)
Verify proxy/load balancer IP handling in each environment
Different IPs may be needed for different environments
Document environment-specific IP configurations
Localhost (127.0.0.1) works for server-based testing

Development Workflows

Team Development

IP Management: Maintain list of all developer IPs
Updates: Update IP list as team members join/leave
VPN: Use VPN with static IP range for easier management

Document process for developers to add their IP. Consider broader range for office network.

Remote Development

VPN: Use VPN for consistent IP addressing
SSH Tunnel: Secure access to staging servers
Multiple IPs: Add home IP plus VPN IP for flexibility

Mobile hotspot IP may differ from home/office. Keep IP list updated as developers work from different locations.

Contractor/Temporary Access

Documentation: Note expiration date with contractor IPs
Removal: Review and remove after project ends
Authorization: Document who authorized each temporary IP

Consider time-limited access mechanisms. Maintain audit log for contractor access.

Configuration Examples

Single Developer

📝 Single Developer IP Configuration

127.0.0.1
192.168.1.100

Development Team in Office

📝 Office Network IP Configuration

127.0.0.1
10.0.1.*         # Office network
74.125.224.100   # VPN exit node

Production Emergency Debugging

📝 Production IP Configuration

203.0.113.50     # Senior admin home IP
198.51.100.10    # Admin via VPN

Production Warning: Use specific IPs only. Remove immediately after debugging is complete.

Load Balanced Environment

📝 Load Balanced IP Configuration

127.0.0.1        # localhost
10.0.1.0/24      # Office network via load balancer
# Configure load balancer to pass X-Forwarded-For header

Load Balancer Setup: Ensure load balancer is configured to pass client IP via X-Forwarded-For or X-Real-IP headers.

Alternative Approaches

Application-Level Filtering

Implementation: IP checking in Application.cfc
Advantages: More granular control than CF Administrator
Features: Database for dynamic IP management, time-based access rules

Allows per-application customization and dynamic IP lists without administrator access.

Authentication-Based Debugging

Method: Require login to enable debug mode
Session: Debug tied to authenticated user
Auditing: Track who enabled debugging

More flexible than IP-based filtering. Works well for dynamic IPs and remote teams.

Separate Debug URLs

Method: Special URL parameters enable debugging
Security: Combine with authentication or shared secret
Control: Enable/disable per request

Easy to enable/disable per request. Can implement custom debug output tailored to needs.

Common Issues and Solutions

IP Filtering Not Working

Symptom: Debug output visible to all users or to none

Solutions:

Verify debug output is enabled in Debug Output Settings
Confirm IP list has at least one entry
Dump CGI.REMOTE_ADDR to see detected IP
Match detected IP to allowed list format (exact match required)
Check for typos in IP address entries
Test with simple single IP before using wildcards

Can't Access from Expected IP

Issue: Added IP but debug output still not showing

Solutions:

Confirm whatismyip.com matches added IP exactly
Check if proxy/load balancer is changing your IP
Look for typos in IP address (e.g., 192.168.1.10 vs 192.168.1.100)
Verify using IPv4 not IPv6 (or vice versa)
Some CF versions may require restart after IP changes (rare but possible)
Use the IP test script above to verify what CF sees

IP Changes Frequently

Problem: Dynamic IP requires constant updates

Solutions:

Use broader IP range: Look up ISP IP range via WHOIS (security trade-off)
Use VPN with static IP: Most reliable solution
Dynamic IP update mechanism: Build admin tool for developers to update their IP
Authentication-based debugging: Use login instead of IP filtering
Wildcard for ISP range: e.g., 71.232.*.* for Comcast range (less secure)

Related Resources

Debug Output SettingsConfigure what debug information to display and performance monitoring options Debugger SettingsLine-by-line debugger IP filtering and configuration Security - AdministratorAdministrator access security and authentication settings ColdFusion Administrator ReferenceComplete administrator guide and settings reference