At 2 a.m., a financial platform's security team completed its move to a DDoS-protected CDN. The website was accessible through the CDN, with DDoS protection, HTTP flood controls, and WAF rules enabled.

The team thought it could finally breathe easier. Then the origin's network link saturated.

The attackers had stopped targeting the website's domain. Instead, they bypassed the CDN and sent attack traffic directly to the trading system's real IP address. The protected edge never saw that traffic and could not scrub it. Within minutes, market data APIs began timing out, users could not log in, and trading APIs started returning 502 and 504 errors.

This is a familiar failure mode.

Putting a DDoS-protected CDN in front of a site is only the first step in hiding its origin IP. If historical DNS records, mobile app configurations, API subdomains, mail servers, test environments, or firewall rules still expose the real address, attackers may bypass every edge control and target the financial platform's origin directly.

For securities, futures, fund, and fintech platforms, effective origin protection also requires consolidating public entry points, changing exposed IP addresses, allowlisting access, cleaning up domains, isolating administrative systems, and continuously monitoring for exposure.

Why must a financial trading system protect its origin IP?

The basic idea behind a DDoS-protected CDN is to route both legitimate users and attack traffic through its edge first.

At the edge, the CDN scrubs DDoS traffic, identifies HTTP floods, applies WAF rules, and controls API access. Only requests that pass these checks are forwarded to the financial platform's origin.

The intended path is: User or attack traffic → CDN07 DDoS-protected edge → Security checks and traffic scrubbing → Financial platform origin

If the real origin IP is exposed, attackers can bypass the CDN: Attack traffic → Financial platform's real IP address

Even a CDN with ample mitigation capacity cannot scrub traffic that never passes through it.

Attackers do not need to compromise a server. Saturating the origin's bandwidth, connection capacity, or firewall session table may be enough to cause:

• Login failures on the website and mobile app;
• Slow responses from market data APIs;
• Widespread WebSocket disconnections;
• Frequent API gateway timeouts;
• Failed order placement and cancellation requests;
• Disrupted connections to databases and internal services;
• Cloud provider blackholing or traffic limits;
• Simultaneous attacks on primary and standby origins.

For a financial platform, protecting the origin IP is fundamental to making the DDoS-protected CDN effective.

Why can the real IP remain exposed after deploying a DDoS-protected CDN?

Many platforms assume that pointing the primary domain to a CDN hides the origin IP. Attackers looking for that address, however, do not limit themselves to the domain's current DNS records.

Common exposure paths include the following.

Historical DNS records still reveal the old origin

Before adopting a CDN, a financial website's primary domain may have pointed directly to servers in the United States, Hong Kong, Singapore, or elsewhere for years.

Even after the domain points to a CDN, historical DNS databases, network scanners, and third-party monitoring services may retain the old resolution results.

If the platform keeps using that origin IP, attackers may find the server through those records.

What to do

After moving to the CDN, replace the origin's public IP as soon as possible rather than continuing to use an address that has already been exposed.

Confirm that the old IP no longer hosts production services and does not forward traffic to the new origin. Otherwise, attackers may follow that old entry point back to the application.

API, market data, and WebSocket subdomains bypass the CDN

The main website may use a DDoS-protected CDN while other service domains still resolve directly to the origin, for example:

• api.example.com
• trade.example.com
• quote.example.com
• account.example.com
• ws.example.com
• download.example.com
• upload.example.com

A single subdomain that bypasses the CDN may reveal the same origin IP used by the main trading system or the address range of the same data center.

Mobile apps are a particular concern. Their pages may load from a CDN domain while login, market data, and trading requests connect directly to an API server. The website appears protected, but the core trading system remains exposed.

What to do

Inventory every internet-facing entry point, not just the website's primary domain.

Websites, mobile apps, APIs, WebSocket services, file uploads, software downloads, and public callback endpoints should use protection appropriate to their protocols and functions.

HTTP and HTTPS services can be proxied through a DDoS-protected CDN. TCP services that cannot use an HTTP proxy require a DDoS-protected TCP proxy, Layer 4 forwarding, or a dedicated network protection solution.

Server IP addresses are hard-coded in the mobile app

Some older financial apps put server IP addresses directly in client configuration or code to avoid DNS lookup time. Others retain both a domain and an IP address, connecting to the backup IP if DNS resolution fails.

This may look like a resilience measure, but it can expose the origin directly.

If a user's device can obtain the address, an attacker may also find it in a publicly available app package, network request, or error log.

What to do

The app should never connect directly to the origin IP. All public requests should enter CDN07's protected network through protected service domains.

If a backup path is needed, configure multiple protected domains or entry addresses rather than giving the client the real origin as a fallback.

Account for users on older app versions when updating the configuration. Fixing only the latest release will not stop older versions from exposing or reaching the origin.

Mail, support, and file services share an IP with the trading system

To conserve server resources, some platforms place the website, mail, customer support backend, file downloads, and trading API on one public IP address.

Even if the website uses a CDN, the mail server's MX record, support system, or file server may still disclose that IP directly.

Attackers need not trace the trading domain. Finding another service on the same address is enough to bypass the CDN.

What to do

The trading system's entry IP should not be shared with:

• Inbound and outbound mail servers;
• The corporate website's administrative backend;
• Online customer support systems;
• Development and test environments;
• File transfer services;
• Remote administration ports;
• Monitoring and logging platforms;
• Third-party callback services.

Public mail, administrative systems, office services, and trading workloads should use separate networks and public addresses. Exposure of a noncritical system should not reveal the core trading origin along with it.

Test environments and temporary domains expose production servers

Development teams may have created test, staged rollout, temporary API, or legacy domains. If their records remain after launch, they may still point to the production origin.

Common examples include:

• A test domain resolves directly to a production IP;
• A staged rollout domain bypasses the CDN;
• An old mobile app domain remains active;
• A temporary debugging domain created by operations stays online indefinitely;
• Third-party monitoring uses a direct-access domain;
• A standby origin domain is publicly accessible.

These entry points see little legitimate traffic and are easy for security teams to overlook.

What to do

Maintain a complete domain inventory and regularly review DNS records, certificates, cloud load balancers, and public IP addresses.

Retire temporary domains when they are no longer needed. Internal monitoring and health checks should use dedicated networks, private addresses, or tightly authenticated entry points. Do not leave a public direct-access domain in place permanently for monitoring convenience.

Outbound connections from the origin reveal its egress address

A financial platform's origin may connect to third-party systems such as payment services, mail platforms, market data providers, SMS services, or fraud prevention systems.

If outbound traffic and inbound application traffic use the same public IP, third-party logs, error messages, or callback settings may record the address.

A breach involving a third-party system, a less secure partner, or a related account could then expose the origin IP.

What to do

Separate the origin's inbound and outbound public IP addresses.

Production servers can reach third-party services through a separate NAT gateway or egress proxy. Even if the egress address is recorded, it will not directly identify the origin entry point receiving user traffic.

Public callback URLs should also use a CDN or security gateway domain so third parties do not connect directly to the core trading servers.

Error pages, response headers, and system details reveal network architecture

When a server returns an error, the response may disclose:

• Internal server addresses;
• Upstream hostnames;
• Actual port numbers;
• Reverse proxy details;
• Debug paths;
• Cloud regions;
• Backend service names.

These details may not include a public IP, but they can help an attacker piece together the platform's architecture.

What to do

Disable debugging output in production, use consistent error pages, and remove server response headers that do not need to be public.

The CDN, reverse proxies, and API gateway should return only the error information users need. Keep stack traces, upstream addresses, and internal routes in protected logs.

What does effective origin IP protection require?

Protecting the origin takes more than one DNS change. It requires a closed access model:

Internet users can access only CDN07; only CDN07 can access the origin.

Several steps are needed to put this model in place.

Step 1: Inventory every public entry point

Start with a complete inventory of internet-facing assets, including:

• The website and mobile pages;
• Domains for static assets;
• Login and authentication APIs;
• Market data query endpoints;
• WebSocket market data domains;
• Account and position APIs;
• Order placement, cancellation, and status APIs;
• KYC file uploads;
• Mobile app installers and update services;
• Third-party callback endpoints;
• Administrative backends and operations access points;
• Primary origins, standby origins, and disaster recovery sites.

Only after identifying all active entry points can the platform decide which traffic belongs behind a DDoS-protected CDN and which services should become private.

The question is not merely whether the primary domain uses a CDN. It is whether anyone can still connect directly to the origin.

Step 2: Route every public-facing service through CDN07

For HTTP and HTTPS services, traffic can be routed to CDN07 through DNS or a CNAME record.

At the edge, CDN07 handles:

• HTTPS connections;
• Caching of static content;
• Forwarding of dynamic API requests;
• WebSocket proxying;
• DDoS traffic scrubbing;
• HTTP flood detection;
• WAF application protection;
• API request rate limiting;
• Bot and anomalous behavior detection.

Users see CDN07's protected edge addresses, rather than the financial platform's origin address.

Different services need different rules. The website, market data feeds, account services, and trading APIs should each have appropriate caching, timeout, rate limiting, and security policies.

Step 3: Move to a new origin IP that has never been public

Treat any origin IP that previously served public traffic directly as exposed.

The right sequence is more than placing the old IP behind a CDN:

1. Connect to CDN07 and test the application;
2. Prepare a new origin IP;
3. Migrate production services to the new address;
4. Update CDN07's origin configuration;
5. Verify that the new origin accepts traffic only from the CDN;
6. Stop serving production traffic on the old IP;
7. Monitor whether the old IP still receives attacks.

The new origin address must not appear in public DNS records, mobile app code, mail configurations, monitoring domains, or third-party callback settings.

If attackers continue to target the old IP while the new origin remains stable, the migration has effectively closed the historical exposure path.

Step 4: Allow only CDN07 origin traffic through the firewall

Keeping an IP undisclosed reduces the chance that attackers will find it. A firewall allowlist is the control that prevents them from bypassing the CDN.

The origin should reject all unnecessary internet access and allow only:

• CDN07's origin-facing nodes;
• Required internal services;
• Authorized operations networks;
• Primary and standby database and application communications;
• Verified monitoring systems.

Even if an attacker discovers the new IP, requests from sources outside the allowlist cannot reach the website or API directly.

After configuring the firewall, verify from an ordinary public network that the origin IP is not directly accessible, while confirming that CDN07 can still fetch from it.

Step 5: Authenticate CDN-to-origin requests as well

An IP allowlist alone is not enough. The platform can add authentication to requests from the CDN to the origin, for example by:

• Encrypting origin connections with HTTPS;
• Validating the certificate used for CDN-to-origin connections;
• Using mutual TLS authentication;
• Checking a dedicated origin request header;
• Verifying request signatures for sensitive APIs;
• Rejecting unknown Host headers and SNI values;
• Rotating origin authentication keys regularly.

A dedicated request header adds a layer of protection but does not replace a firewall allowlist. Ordinary headers can be forged. A reliable origin boundary combines source-network restrictions with authentication.

Step 6: Separate administrative access from the trading entry point

Operations backends, database administration, logging platforms, and remote server access should not be exposed directly through a public CDN domain.

Safer access methods include:

• An enterprise VPN;
• A zero trust access system;
• A bastion host;
• A dedicated management network;
• An identity-aware proxy;
• Multifactor authentication;
• Device trust checks.

The management plane and user-facing trading services must be separate. An attack on the public website should not prevent operators from reaching administrative tools to resolve an incident. Likewise, a compromised administrator account should not directly expose the trading system's entry point.

Step 7: Protect the chain of trust for client IP addresses

After adopting a CDN, the origin generally sees connections from the CDN's origin-facing nodes, not users' real IP addresses. Financial platforms still need client IPs for login risk checks, device identification, and security audits.

CDN07 can forward the actual client IP to the origin in a controlled request header. The origin must trust that header only when the request comes from a CDN07 origin-facing node.

If the origin accepts a “real IP” header from any public request, an attacker can forge client identity and compromise risk analysis and audit records.

The trust model should therefore be:

• Public traffic can reach only CDN07;
• The origin accepts requests only from CDN07's origin-facing addresses;
• Only client IP headers supplied by CDN07 are trusted;
• The API gateway records client IP, account, and device information consistently.

Step 8: Apply the same security boundary to primary and standby origins

Some platforms protect the primary origin but leave the standby origin directly accessible from the internet.

Once attackers find the standby server, they can attack it directly or force the primary system to fail over to a disaster recovery environment that is already saturated.

The primary origin, standby origin, and disaster recovery site should all:

• Protect their real IP addresses;
• Allow origin requests only from CDN07;
• Use HTTPS or mutual TLS;
• Close unnecessary ports;
• Follow the same security baseline;
• Feed into centralized monitoring and alerts;
• Undergo regular failover tests.

A disaster recovery system cannot receive weaker protection simply because it is rarely used. It must be ready to take over critical services at any time.

What about FIX, TCP, and other non-HTTP trading services?

Some securities platforms use FIX, proprietary TCP protocols, or other long-lived Layer 4 connections alongside their websites and REST APIs.

A standard HTTP CDN cannot proxy those services. If they remain exposed to the public internet, attackers may still find or target the core data center through them.

Depending on the protocol, CDN07 can configure a DDoS-protected TCP proxy, Layer 4 forwarding, and a separate protected entry point. Users or partner institutions connect to the protected address first, and traffic then travels over a protected path to the real server.

Institutional trading interfaces such as FIX should also use:

• Allowlisted counterparties with fixed addresses;
• Mutual certificate authentication;
• Dedicated circuits or encrypted tunnels;
• Separate ports and network segments;
• Session-level authentication;
• Connection and rate limits.

Protection for a public website and protection for an institutional trading channel require distinct designs.

Common misconceptions about hiding the origin

Misconception 1: Pointing the domain to a CDN makes the origin safe

If the origin still accepts connections from any public IP, attackers who find its address can bypass the CDN.

Misconception 2: Keeping the old IP provides a convenient rollback path

If the old IP still connects to the new system, it becomes a fallback path for attackers around the protected network. Rollback should use protected standby domains and edge locations, not a publicly accessible old origin.

Misconception 3: Protecting the website is enough; the APIs can stay exposed

For a financial platform, APIs and market data systems are often more critical than the website. Attackers may ignore the homepage and target login, market data, or trading endpoints directly.

Misconception 4: A secret request header is sufficient

Headers can be forged. The origin also needs a firewall allowlist, HTTPS connections from the CDN, and appropriate authentication.

Misconception 5: No one knows the origin IP, so it can stay in place

An IP that has ever been public may have been recorded. Historical DNS, monitoring services, mobile apps, and third-party systems can all retain it.

Misconception 6: Enough mitigation bandwidth makes origin IP protection unnecessary

Even extensive mitigation capacity can scrub only traffic that passes through protected edge locations. Bandwidth at the edge cannot help if an attack reaches the origin directly.

How can you verify that the origin IP is protected?

After deployment, conduct an independent check rather than relying only on a “connected” status in the CDN dashboard.

Check whether:

• Every public domain resolves to CDN07;
• Historical or temporary domains still point to the new origin;
• Any mobile app hard-codes an IP or direct-access address;
• Every API and WebSocket connection passes through protected edge locations;
• Mail, support, or download services share an IP with the trading origin;
• The origin is directly accessible from an ordinary public network;
• Requests without the correct Host header or authentication are rejected;
• The origin firewall permits only CDN07 origin traffic;
• Management ports are exposed to the public internet;
• Primary and standby origins follow the same security policy;
• Logs record the actual client IP correctly;
• The old origin IP has stopped serving traffic entirely.

Origin IP protection is not a one-time setting. New domains, app releases, data center migrations, and third-party integrations can create new exposure paths.

How does CDN07 build end-to-end origin protection for trading systems?

CDN07 does more than put a proxy in front of a financial website. It establishes a security boundary from the public entry point to the origin.

For securities and financial platforms, CDN07 can provide:

• A unified protected entry point for websites, mobile apps, APIs, and WebSocket services;
• DDoS traffic scrubbing and HTTP flood protection;
• WAF and API access controls;
• Acceleration for dynamic requests and cross-border network paths;
• Origin IP protection;
• Origin access allowlists;
• Encrypted HTTPS connections to the origin;
• Authentication for origin requests;
• Health checks across multiple origins;
• Automatic failover;
• Real-time logs and attack alerts;
• Protected access for TCP and other non-HTTP services.

Platforms can keep their existing servers in the United States, Hong Kong, Singapore, or elsewhere while gradually migrating traffic through domain-based onboarding. CDN07 can tailor caching, dynamic acceleration, security, and origin routing rules to the different needs of the website, market data, login, account, and trading services.

For an already exposed IP, CDN07 can work with the platform to replace the origin address, shift traffic gradually, and tighten firewall access. There is no need to move every trading service at once. The platform can start with the website and static assets, then add market data, APIs, and WebSocket services in stages.

The result is more than a domain that no longer reveals the origin. It is a complete protection path:

CDN07's protected edge scrubs attack traffic. Legitimate requests reach the origin over protected cross-border paths, and the real servers reject unauthorized public connections.

Protect the trading system, not just the domain

The most dangerous state for a financial platform is assuming that deploying a CDN has made the system safe.

One legacy domain, API record, mobile app fallback address, or test server that still reveals the real IP could let attackers bypass the protected edge and strike the trading system directly.

Effective origin protection requires all of the following:

• Route all public traffic through CDN07;
• Replace previously exposed origin IP addresses;
• Allow CDN07 alone to connect to the origin from the public internet;
• Bring websites, mobile apps, APIs, and WebSocket services under the appropriate protection;
• Keep the management plane separate from user-facing trading systems;
• Apply the same security policies to primary and standby servers;
• Continuously monitor for new IP exposure.

Preventing attackers from finding the origin is the first layer. Effective origin protection also prevents a direct connection if they discover the new IP.

For financial platforms that cannot tolerate downtime, interrupted market data, or unavailable trading APIs, a DDoS-protected CDN is most valuable when it closes direct attack paths before an incident begins.