Secure proxy access: credentials or an IP allowlist

When credentials work best

Credentials are convenient for a laptop, browser profile, or application whose network changes often. Create separate credentials for a defined task and rotate them when access changes hands. Do not place a connection string in a page URL or support ticket, because browsers and analytics may retain it.

• Store connection strings in a password manager.
• Keep them out of shared screens and training recordings.
• After exposure, generate new credentials and treat the old ones as compromised.

How IP access works

The service compares the incoming connection with an allowlist. In WorldProxy, enter one public IPv4 or CIDR per line. A single address looks like 203.0.113.10 and a corporate range like 203.0.113.0/28. These examples use documentation space and are not live addresses.

• Find the public static IP of the office or server.
• Allow the smallest necessary range.
• Remove old addresses after a move or ISP change.
• An empty list disables IP access and returns to credential access.

Why an allowlist may fail

Home addresses often change, mobile networks use shared NAT, and a VPN exposes its server address. Check the public IPv4 from the device that will connect. For cloud applications, allow the cloud server's outbound address rather than the laptop address.

• Do not enter private 10.x, 172.16–31.x, or 192.168.x addresses.
• Put every entry on its own line; commas are unnecessary.
• Test the connection after saving, then remove credentials from the application if IP-only access is intended.

A minimal security record

Record who changed access, when, and for which proxy. Never log the password itself. An event such as “credentials changed” or the approved IP list is enough. WorldProxy command history shows the action and its outcome.

Choose and migrate access

Credentials fit changing networks; an IP allowlist fits a server with a stable outbound address. Verify the address from the actual process, because offices, cloud NAT, VPNs, and home links can expose different IPs. Use one IPv4 or CIDR per line and never widen a range merely to make a test pass.

Enable and test the new access method before revoking the old one. Confirm both a successful connection and rejection from an unauthorized address or old password. Keep time, proxy ID, actor, and result in history, but never retain the secret itself.

• Use the real outbound IP
• Enter one IPv4 or CIDR per line
• Test before revocation
• Verify the negative case

Review access over time

Quarterly, compare allowlists and credentials with active systems and staff. Remove temporary access after projects and rotate anything exposed in logs or screenshots. A support case should include proxy ID, time, client type, code, and connection stage with all secrets and unrelated tabs removed.

Worked example: moving a server to an IP allowlist

An operator discovers the public IPv4 from the actual cloud job, adds that single /32 while old credentials still work, and runs one request to an owned endpoint. A negative request from an unapproved network must fail before the origin.

The workload is switched during a bounded window and observed for authorization errors and exit IP. Old credentials are revoked only after success, then explicitly tested for rejection. Multiple documented NAT exits are entered one per line rather than replaced with a broad range.

The operating record has owner, purpose, allowed addresses, review date, and revocation procedure. Quarterly review removes orphaned access, and support evidence contains proxy ID, time, client, stage, and safe error code without reusable secrets.

The failure plan forbids automatic widening when the cloud exit changes. An operator confirms the new address from infrastructure data, adds one line, runs the positive and negative controls, and removes the obsolete entry after observation. Every exception has an owner and expiry.

Logs, browser history, CI output, and support attachments are checked for connection URLs. Any exposed credential is rotated rather than merely hidden in a later message. Evidence records the event and result while keeping both old and replacement secrets out of durable storage.