TL;DR
Security functions should not be confined to a single location. The edge is suitable for protective measures with high visibility, significant scaling needs, and standardizable rules. The application remains responsible for identity, authorization, and business access controls. Key factors include context requirements, misconfiguration risks, and how early an attack can be detected and mitigated.
Introduction
A common architectural mistake is to shift security responsibility entirely to the edge or entirely to the application. Both create blind spots: An edge can intercept volumetric attacks and many HTTP patterns early but usually lacks understanding of the business significance of a transaction. The application can assess users, roles, and business objects, but this decision is made only after traffic has already burdened infrastructure and runtime. A robust model distributes security functions according to their visibility, context requirements, and scaling needs. Misconfigurations must also be considered: A misplaced or overly broad rule can either lose protective effect or block legitimate requests.
1. Visibility Determines the Appropriate Security Layer
The edge sees public traffic before it reaches the backends. It can evaluate source networks, protocols, ports, TLS connections, HTTP requests, headers, and typical attack patterns. This visibility suffices for DDoS defense, rate-limiting concepts, broad access patterns, and many WAF checks. The advantage lies in early decision-making: Malicious traffic consumes fewer resources in load balancing, clusters, and applications.
The application, on the other hand, possesses additional information. It knows user accounts, roles, tenants, shopping carts, approval statuses, or the permissible state transitions of a transaction. This information is indispensable for business access controls. An edge rule can recognize that a request calls /api/orders/123. However, without application context, it does not know if the authenticated user is allowed to view this order. Thus, visibility is the first decision criterion: What is recognizable at the network or HTTP edge can be protected there; what requires business logic must be decided in the application.
2. Scaling Favors Early Defense
DDoS defense and standardizable WAF checks benefit from upstream, distributed enforcement. The earlier invalid or abusive requests are discarded, the less work arises in firewalls, ingress components, API processes, and databases. This is not only a security issue but also a matter of availability and operational costs. Protection directly in the application scales with its resources and can become a bottleneck under high attack pressure.
The ayedo Edge Cloud takes on DDoS protection and scrubbing at the edge as the public entry point, along with WAF functions for HTTP and HTTPS services. TLS termination can additionally help centrally inspect encrypted requests before forwarding. Backend cloaking reduces the direct visibility of the actual backends. These functions do not replace application security. However, they shift the first protection decision to a location where traffic can be centrally, distributedly, and pre-compute infrastructure evaluated.
3. Identity and Authorization Need Application Context
Authentication and authorization are often mixed. Authentication answers who a caller is. Authorization decides what this caller is allowed to do under certain conditions. Depending on the architecture, a central edge component can take over the verification of tokens or client certificates. Whether this function is sensible depends on the existing identity sources, protocols, and trust boundaries. It should not automatically be understood as a replacement for every check in the application.
The application must continue to ensure that identity, tenant, resource, and action match. Especially with APIs, a broad rule like "logged-in users may call /orders" is not sufficient. It may be necessary for a user to only read orders of their tenant or to change a transaction only in a specific status. Such rules belong in the application or in a closely coupled policy layer. An edge check can reduce load and reject obviously invalid accesses but cannot reliably anticipate the business decision.
4. Misconfiguration as Its Own Decision Criterion
Each security layer creates operational risks. An overly restrictive WAF rule can block legitimate requests, while an overly permissive rule allows attacks to pass. In the application, inconsistent checks can arise: One endpoint validates tenant affiliation, another forgets it. Distribution should therefore not only occur based on technical feasibility but also on the likelihood and impact of misconfigurations.
Edge rules are suitable for centrally visible, traceable protection requirements: allowed protocols, known attack patterns, broad request limits, or shielding of non-public backends. Business policies should be close to the domain models and operated with tests, code reviews, and traceable change processes. Observability is also important: Blockages at the edge and rejections in the application must be distinguishable. Traffic and usage statistics from the edge can make the effect of upstream rules visible; application logs explain why a business decision was rejected.
Practical and Operational Scenario
A company operates a public API on a Kubernetes cluster. The edge handles Anycast-based Layer-7 load balancing, TLS termination, WAF checks, and DDoS defense. Non-public backend addresses are hidden through backend cloaking. The application then checks tokens, tenant affiliation, and authorization for individual resources.
When a change introduces a new parameter that the WAF initially blocks as suspicious, edge statistics show increased rejections while the application sees no corresponding requests. The rule can be specifically adjusted without altering the business authorization checks. Conversely, a faulty tenant check remains an application problem and is not solved by a generic edge rule. This model clearly separates infrastructure and domain responsibility.
FAQ
Should every WAF rule also be implemented in the application?
No. WAF rules and application validation have different goals. Security-critical inputs must be validated in the application independently because only it knows their business context.
Can the edge fully take over authorization?
Only for clearly defined, context-free rules. Resource and transaction-related permissions belong in the application, where identity, tenant, and business status are combined.
Why is DDoS protection in the application not sufficient?
The application only becomes active after traffic has reached the network, routing, and runtime. Upstream defense reduces resource consumption and protects even when the application itself is already overloaded.
Conclusion
Security functions should be distributed according to their decision basis. The edge protects what is early visible, standardizable, and scaling-relevant. The application decides where identity, resources, and business logic interact. For companies, this is not an either-or but a coordinated security layer model. The ayedo Edge Cloud is the public protection and distribution point in this model; authorization and business access control remain the responsibility of the respective application.