Why filtering at the edge changes the game
When your application server does its own security checks, every malicious request still reaches it, consumes CPU, opens a database connection, and competes with real users for resources. cdn.com.tr moves that inspection to the edge, so injection attempts, scanner probes, and junk traffic are rejected far from your origin and never touch your code or your database. This is the difference between a server that buckles under an attack and one that barely notices it, because the abusive load is absorbed by a distributed network built to take it.
The managed WAF rule set
The web application firewall inspects request method, path, headers, and body against rules that recognize the well-known attack classes: SQL injection, cross-site scripting, remote file inclusion, path traversal, and command injection among them. These rules are maintained centrally so you benefit from updates without editing your own configuration, which matters most for platforms like WordPress and legacy PHP where the application itself may be slow to patch. You can enable protection per domain and layer your own allow and deny rules on top for application-specific paths.
Absorbing DDoS floods
A distributed denial-of-service attack tries to exhaust your capacity by sending far more traffic than a single origin can answer. Because cdn.com.tr fronts your domain with a distributed edge, volumetric floods are spread across the network and filtered before they concentrate on your server, and cached responses continue to be served from the edge even while an attack is in progress. The practical outcome is that your origin stays reachable for legitimate visitors during exactly the moments an unprotected site would go dark.
Rate limiting and bot mitigation
Not every threat is a signature; some are simply too many requests from one client. Rate limiting lets you cap how often an IP can hit sensitive endpoints such as login forms, password resets, or expensive API routes, which shuts down brute-force credential stuffing and aggressive scraping without blocking normal users. Combined with country and IP access rules, this gives you a way to stop abusive automation that a signature-based firewall alone would miss, all configured per domain from the panel.
Hiding the origin removes the bypass
A firewall at the edge only works if attackers cannot go around it, and the classic mistake is leaving the origin server reachable on its real IP. cdn.com.tr encourages you to lock the origin so it accepts connections only from the edge and to keep its address out of public DNS, which means the only path to your application runs through the security layer. This origin shielding turns the WAF from an optional speed bump into a mandatory checkpoint, and it also shrinks the attack surface exposed to internet-wide scanners.
One security policy across every app you run
Whether you publish a WordPress site, a legacy PHP portal, or a container-based API, the same edge security model applies once the domain is routed through cdn.com.tr. That means you do not maintain a separate firewall stack per application; you attach the domain, enable the WAF, set rate limits, and the policy protects it uniformly. For teams running several sites or services, this consistency is what makes security manageable instead of a per-project scramble.
How to set it up, step by step
Route the domain through the edge
Add the hostname to your CDN account and point its DNS at the cdn.com.tr edge. From that moment every request for the domain enters an edge node first, which is the prerequisite for any security policy to apply, because a firewall only helps if all traffic actually passes through it.
Enable the WAF for the domain
Turn on the web application firewall in the panel for that domain. The managed rule set immediately starts inspecting requests for common attack signatures such as SQL injection, cross-site scripting, and path traversal, with no changes to your application.
Hide and lock down your origin
Once traffic flows through the edge, restrict your origin so it only accepts connections from cdn.com.tr and stop publishing its real IP in public DNS. This closes the bypass where an attacker hits the origin directly and skips the WAF entirely.
Add rate limits and access rules
Configure rate limiting on sensitive endpoints such as /wp-login.php, /xmlrpc.php, or your API's auth route, and add allow/deny rules by country or IP where needed. This stops brute-force and scraping abuse before it consumes application resources.
Confirm TLS and force HTTPS
With Auto SSL in place, enable HTTPS redirection so every request is upgraded to TLS at the edge. This ensures the traffic being inspected and forwarded to your origin is encrypted end to end for visitors.
Watch, then tune
Review what the WAF is blocking, confirm legitimate traffic is not caught, and adjust rules or exceptions for the rare false positive. Security is a policy you refine over time, not a switch you flip once, and the panel gives you the visibility to do it safely.
Example scenarios
A WordPress site enables the WAF and rate-limits /wp-login.php and /xmlrpc.php, cutting off brute-force bots at the edge so the PHP process and database are never touched by the attack traffic.
A container-based JSON API is published with the WAF enabled and per-route rate limits, so scraping and injection attempts are filtered before they reach the service, while the origin is locked to accept only edge connections.
Ahead of a high-visibility launch, a site relies on edge DDoS absorption and cached delivery so that a sudden surge, whether real visitors or an attack, is spread across the network instead of collapsing the origin.
Frequently asked questions
Do I have to change my application code to use the WAF?
No. The firewall operates at the edge on the request path, so it inspects and blocks traffic before it reaches your application. You enable it per domain in the panel; your code, framework, and server configuration stay exactly as they are.
What kinds of attacks does the WAF actually stop?
The managed rule set targets common web attack classes including SQL injection, cross-site scripting, path traversal, remote file inclusion, and command injection, plus abusive volume through rate limiting. It is designed to catch the automated probing and exploitation attempts that make up the bulk of hostile web traffic.
Can attackers bypass the WAF by hitting my origin directly?
Only if you leave the origin exposed. The recommended setup locks your origin to accept connections from the cdn.com.tr edge and keeps its real IP out of public DNS, so the single path to your application runs through the security layer and direct-to-origin attacks are cut off.
Will the WAF block legitimate visitors by mistake?
False positives are possible with any firewall, which is why the panel lets you see what is being blocked and add exceptions for specific paths or clients. The practical approach is to enable protection, watch the results, and tune rules so genuine traffic flows while attacks stay blocked.
How is DDoS protection different from the WAF?
They solve different problems. The WAF inspects the content of individual requests for malicious patterns, while DDoS protection deals with sheer volume by spreading and absorbing floods across the distributed edge. A serious attack often involves both, so the two layers work together in front of your origin.
Does enabling security slow my site down?
The edge already sits in the request path for caching, so adding WAF inspection there does not introduce a separate hop, and cached responses are still served fast. In practice the same layer that protects you also accelerates you, since blocked and cached traffic never burdens your origin.