On the same SaaS platform, one customer can log in while an entire office at another company hits a rate limit. Static pages load quickly, but real-time notifications keep disconnecting. Enabling caching raises another concern: could one tenant receive another tenant's data?

For SaaS, confirming that the site loads is only the start of integration testing.

When choosing a DDoS-protected CDN for a SaaS platform, test multi-tenant data isolation, compatibility with login flows and APIs, and persistent connection stability first. Then compare network routes, mitigation capacity, and cost.

A cross-tenant data leak, a broken identity flow, or an unstable connection can outweigh any improvement in home page speed.

Why SaaS needs different CDN evaluation criteria

Multi-tenancy means several organizations use the same platform while maintaining separate accounts, data, and permissions. They may share servers, databases, and entry points, but their data and access boundaries must remain clear.

That means evaluating more than one domain. A SaaS platform may have a main site, tenant subdomains, customer-owned domains, login flows, APIs, file downloads, and real-time connections that all work together.

For example, ten tenants sharing one public egress IP are not a single user. Nor should one tenant's burst of report exports automatically consume the API capacity available to the whole platform. CDN configuration must work with the application's identity, quota, and resource controls.

In a multi-tenant system, first check whether cached content can cross boundaries

How do domains, paths, and headers affect the response?

Common ways to serve tenants include:

• Subdomains: tenant-a.example.com and tenant-b.example.com.
• Paths: example.com/tenant-a/ and example.com/tenant-b/.
• Shared API: The path is the same, while a session or token identifies the tenant.
• Custom domains: Each customer uses its own branded domain.

A CDN typically uses a cache key to distinguish cached objects. Think of it as the identifier that determines whether two requests can share a response. Check that the actual rules distinguish domains, paths, and parameters that affect content. Pay particular attention to custom cache keys, ignored query parameters, and path rewrites.

For example, two companies request the same /api/report path but receive different business reports. Caching only by path could serve the wrong response. Even when the cache key includes a tenant ID, an admin and a regular user within that tenant may have different permissions.

Keeping cached objects separate does not mean a request has passed authorization.

Start by bypassing shared caches for sensitive responses that require login or depend on user permissions. If caching is necessary, design trusted identity checks, appropriate isolation dimensions, and invalidation rules first.

As OWASP emphasizes in its Multi-Tenant Security Cheat Sheet, a tenant identifier supplied by the client may select a target, but the server must still verify that the current user may access it. The presence of an X-Tenant-ID header does not establish authorization.

A Cookie or Set-Cookie header does not automatically prevent caching

A common assumption is that a CDN will naturally bypass cache when an API request includes a login Cookie. Actual behavior varies by product, rule, and override. Do not rely on a default as a security boundary.

The IETF's HTTP caching specification, RFC 9111 states that Set-Cookie alone does not prevent caching. Use appropriate cache directives to control storage, and check for CDN overrides such as forced caching.

For sensitive responses that must not be stored, the application can return the following response header. Verify the actual behavior after integration:

Cache-Control: no-store

This is an example HTTP response header, not a terminal command or a rule to apply to every endpoint. Public help pages, versioned scripts, and images may use different caching policies based on their content.

Test at least two tenants, different roles within the same tenant, and unauthenticated access. Use separate browser sessions to visit the same application paths and verify who owns the returned data. After logout, removing a member, or reducing permissions, confirm that previously accessible data can no longer be retrieved.

Have tenant A request a resource, then tenant B request the corresponding URL; reverse the order and repeat. Cover both cache hits and origin requests. Give each tenant distinct, recognizable test data so identical sample values do not hide an incorrect cache reuse.

Custom domains also need onboarding and offboarding procedures

For a SaaS platform serving enterprise customers, domain management is ongoing. Adding customers, renewing certificates, disconnecting domains, and customer churn all require procedures.

When evaluating a provider, ask how many custom domains it supports, how domain ownership is verified, how certificates are managed, whether rules can be applied in bulk, and how domain-to-tenant mappings are removed after disconnection. A wildcard certificate does not cover arbitrary domains owned by customers.

You cannot infer these capabilities from “supports multiple domains.” At scale, the time spent configuring domains one by one belongs in the operational cost estimate.

How can login protection avoid blocking an entire company?

Per-IP rate limits must account for shared corporate egress

Offices, campuses, and mobile networks can put many legitimate users behind one public IP address. A simple per-IP threshold may block people during a morning login surge, bulk page refreshes, or client synchronization.

Meanwhile, distributed credential stuffing can spread requests across many IP addresses. Each source appears relatively quiet while an account still receives repeated password attempts.

OWASP's Authentication Cheat Sheet recommends associating failure counts with accounts and notes that account lockouts can themselves be abused to deny legitimate users access. Evaluate source, account, and application behavior together rather than only raising or lowering one IP threshold.

Divide responsibilities: The CDN handles abnormal traffic at the entry point and request characteristics it can identify. The application manages account state, authentication, tenant permissions, and quotas that require a trusted identity. Verify whether a specific CDN plan supports rules at the necessary level; do not assume it understands your account and tenant model.

Test the login page, submission, and identity callback separately

A SaaS login flow may include single sign-on (SSO), multifactor authentication, identity provider redirects, callbacks, and token refresh. A working login page confirms only one part of that flow.

At a minimum, identify these paths:

Do not force browser challenges on every machine-to-machine API. A client expecting JSON may fail when it receives an HTML challenge page, even with a 200 status code. Disabling site-wide protection just to make callbacks work expands exposure as well.

For endpoint classification and rule design, see how to protect APIs from abusive request volume, and handle login, queries, exports, and third-party calls separately. For the roles of different security controls, see how WAF, bot management, and DDoS protection work together.

What should you test for WebSocket and SSE connections?

Identify the connection type before asking about limits

Real-time notifications, collaboration, and AI-generated output may use WebSocket or SSE. The two are not interchangeable.

WebSocket supports ongoing two-way communication. Under RFC 6455, the WebSocket protocol, data exchange continues after the connection is established, so a successful handshake is far from a complete test.

With SSE, the server continuously sends events to the client over HTTP. MDN's guide to using server-sent events explains that the stream uses the text/event-stream media type and separates messages with blank lines. After integration, verify that events arrive progressively rather than being held and delivered all at once at the end.

WebSocket support does not establish that SSE or other streaming protocols work as your application expects. Ask separately about idle timeouts and maximum connection duration; heartbeats do not prevent every disconnection.

Test whether SSE events arrive incrementally

On a Linux or macOS terminal with curl installed, use the following command to check a test event stream. Replace the example URL with your SSE endpoint. If it requires authentication, use a dedicated test session instead of exposing a production endpoint for the test.

curl -N -sS --connect-timeout 5 --max-time 30 \
  -H 'Accept: text/event-stream' \
  -D - \
  'https://example.com/events'

According to the curl documentation, -N disables curl's own output buffering. It does not disable buffering in the CDN, gateway, or origin. --max-time 30 limits the entire test to 30 seconds.

Check the response type, event content, and timing. If the test origin sends events at a known interval but the client receives them in batches, compare origin send logs with client receipt times to locate buffering along the path. That symptom alone does not prove the CDN is responsible.

A 401 or 403 may reflect a missing login or an access policy; establish a valid test identity first. The command deliberately stops after 30 seconds and may report a timeout, which does not by itself mean the service failed. This is a short connectivity and output check. Acceptance testing must also cover the required connection duration, idle periods, and recovery from network loss.

Do not shift all reconnection load onto the login service

After an edge change, client network change, or deployment, many connections may be reestablished within a short period. If each connection refreshes a token, checks permissions, and resubscribes at once, authentication and subscription services can become the next bottleneck.

Test client backoff and jitter, reauthentication, subscription recovery, message deduplication, and any required replay mechanism. Automatic SSE reconnection does not mean the application can replay missed events. A reconnected WebSocket does not automatically restore session state.

The application must continue to enforce tenant, channel, and message permissions after a persistent connection is established. When evaluating a CDN, distinguish inspection of the handshake request from inspection of messages within the connection. They are separate capabilities.

If one tenant is attacked, can the others keep working?

Multi-tenant availability depends on more than the CDN. Heavy traffic from one tenant can consume shared application threads, database connections, export queues, or file-processing resources.

Evaluate two layers: Can controls at the entry point limit the impact of abnormal traffic? Does the application set appropriate boundaries for each tenant's concurrency, jobs, and resource use?

Tenant-level rate limits must use a trustworthy identity. A client must not be able to change a request header to bypass a quota or charge its usage to another tenant. Requests made before login, when there is no trusted tenant identity, need a separate entry-point protection policy.

Operations teams should look beyond platform-wide averages. At a minimum, they need to correlate affected domains, paths, rules, and time periods with application records before deciding whether a problem comes from CDN blocking, an origin connection failure, or application processing. Trusted application logs can supply the tenant dimension; do not assume every CDN reports it directly.

Avoid logging passwords, complete tokens, or sensitive application payloads. Request and tenant IDs used for correlation also need a defined source and access controls.

How should routes and pricing figure into a SaaS CDN comparison?

A SaaS API with small responses may use little bandwidth but receive requests at a high rate. A real-time collaboration platform may transfer modest amounts of data while maintaining many connections. Estimating the entire cost from monthly traffic alone can miss important charges.

When requesting a quote, list the number of domains, monthly traffic, peak request volume, concurrent connections, new connection rate, logging requirements, and necessary security features separately. Confirm whether each item is billed, how it is measured, and what the plan includes.

Growth in custom domains for large customers, longer log retention, and a mass reconnection can all change resource requirements. Use the breakdown of DDoS-protected CDN plans, standard traffic, and additional charges to estimate both a typical month and peak activity.

Break down route testing by workload: static assets depend on delivery, login and queries on dynamic origin connectivity, and real-time features on continuous delivery and recovery. If the origin is outside Mainland China and most enterprise customers are there, use the guide to performance and protection for Mainland China access to international origins to cover key regions, carriers, and working hours.

As part of your evaluation, you can test the CDN07 DDoS-protected CDN service. It combines content delivery with DDoS protection, lists WebSocket support, and offers options to tailor edge locations, bandwidth, and security policies. These are starting points for discussing SaaS fit. Verify tenant caching rules, SSO compatibility, SSE behavior, and quota management individually rather than inferring them from the product name.

Trial checklist: What must work before rollout?

In an authorized test environment, prepare two tenants, accounts with different roles, and real clients. Verify correctness before evaluating performance and protection. Do not simulate credential stuffing in production or run load tests without an agreed scope.

Resolve failed tenant isolation, broken core identity flows, or incompatible persistent connections required by the application before expanding the rollout. More mitigation capacity or faster static-asset tests do not compensate for those problems.

Frequently asked questions

Can a CDN cause one SaaS tenant to see another tenant's data?

Incorrect shared caching or authorization settings can create that risk, but it is not an inevitable result of using a CDN. Distinguish public, tenant-specific, and user-specific content, and test cache hits, logout, and permission changes.

Is a separate subdomain for every tenant enough to isolate data?

No. Check cache keys, origin mappings, application authorization, and data access. A custom rule that treats different domains as one, or an application that fails to verify tenant permissions, can still cross boundaries.

If employees are rate limited when they log in together, is protection too aggressive?

The rules may not account for shared egress and coordinated login activity, though other causes are possible. Review matched rules, account behavior, and application logs. Simply raising the IP threshold or turning protection off is not enough.

Does a DDoS-protected CDN that supports WebSocket also support SSE?

You cannot assume so. Test SSE's continuous HTTP response, buffering, caching, and timeouts separately. For WebSocket, test both the connection and message handling. Include both in acceptance testing.

If SSE output arrives all at once at the end, did the CDN cache it?

Not necessarily. The application, reverse proxy, compression, CDN, or client can affect when output appears. Compare send and receive records at each layer to locate buffering and flush behavior.

Can a DDoS-protected CDN replace SaaS account and tenant authorization?

No. A CDN can provide applicable entry-point protection, but trusted application logic still needs to enforce account state, tenant membership, object-level permissions, and usage quotas.

Test real application workflows when choosing a provider

Focus the SaaS CDN evaluation on four outcomes:

• Tenant and user permissions remain correct after a cache hit.
• Login, SSO, and machine-to-machine APIs still work with protection enabled.
• Persistent connections stay active and recover appropriately after disruption.
• Abnormal activity from one tenant, incident response, and cost growth remain manageable.

Next, document how tenants access the platform, domain counts, login flows, persistent connection types, peak usage, and the main user regions. Select representative tenants for testing.

If you plan to test CDN07, share these requirements through a DDoS-protected CDN integration consultation and put nonnegotiable conditions on the test checklist. Tenant isolation, successful login, and sustained communication are more meaningful measures of SaaS fit than mitigation capacity alone.