Only when the business does not need them, because these services are legitimate and broad blocking can create unnecessary disruption. A better approach is to inventory who uses them, create narrow exceptions and alert on unexpected combinations such as browser-initiated RPC calls followed by local script execution.
When blocking public RPC endpoints and CDNs is the wrong default
Public RPC endpoints and CDNs are often part of normal application delivery, update distribution, telemetry, and third-party service integration. Broadly blocking them can break legitimate software, push teams toward brittle workarounds, and reduce visibility into the traffic you still need to inspect. The better question is which business flows actually depend on them, and whether the endpoint or content is expected in that environment.
The practical decision is not “allow or deny everything,” but “is this service required, and can we constrain it enough to detect abuse?” That usually means inventorying the dependency, narrowing where it is reachable, and treating unusual pairings as suspicious, especially when a browser session makes an RPC call and then launches local execution shortly after.
For delivery-path abuse, the relevant control point is often the trust boundary around software distribution, not the endpoint category itself. If a CDN is serving a signed and expected artifact, blocking the CDN indiscriminately may not stop malware so much as disrupt normal updates while attackers switch to another path. That is why allowlisting known sources, constraining destinations, and checking the follow-on behavior matter more than blanket network denial. CIS Controls v8 aligns with that approach because it emphasises asset inventory, secure configuration, and malware defence as operational safeguards.
RPC deserves the same nuance. Many public RPC services are legitimate interfaces to cloud, blockchain, developer, or enterprise platforms, and they can be abused only when the request pattern, source, or downstream action does not fit the approved use case. The control objective is to make approved RPC use observable and exceptional RPC use noisy, rather than to assume that all public RPC is malicious. Where the traffic is API-like, OWASP API Security Top 10 is a useful reference point for thinking about weak authentication, broken authorisation, and abuse of exposed functions.
Risk and Threat Considerations
Public RPC endpoints and CDNs create exposure when teams assume that “public” means “safe by design” or “unsafe by default.” Attackers can hide delivery infrastructure inside normal-looking traffic, then use the same distribution path to stage payloads, fetch scripts, or pivot from initial access to execution.
Failure mechanism: Security teams block the service category too late or too broadly, which either leaves the malicious path untouched or forces users and applications to route around the control. In parallel, defenders may miss the more useful signal: a permitted service being used in an unusual sequence, such as a browser-originated RPC request followed by local script execution or downloader activity.
Impact: The result is either preventable disruption or missed malware delivery. In environments that rely on CDNs or public RPC for normal operations, the real risk is not just blocked traffic, but loss of fidelity in allowlist, exception, and detection logic that attackers can exploit to blend into expected network behaviour.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Public endpoints and CDNs require inventory and access control around legitimate use. |
| Recommendation — Inventory permitted endpoints and restrict access paths to approved business uses. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Public RPC endpoints often fail through weak exposure and unsafe default access settings. |
| Recommendation — Harden exposed RPC surfaces and remove unsafe public defaults. | ||
| MITRE ATT&CK | T1105 — Ingress Tool Transfer | CDNs and RPC endpoints can deliver payloads and staging content used in malware delivery. |
| Recommendation — Hunt for unexpected payload retrieval and staged transfer activity. | ||
| NIST CSF 2.0 | PR.PS-03 — Configuration management | Selective blocking and exception handling depend on controlled configuration of exposure paths. |
| Recommendation — Maintain approved exposure rules and review exceptions for drift. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | The question is about stopping malware delivery through network paths and distribution services. |
| Recommendation — Inspect and block malicious content delivery using layered malware protection. | ||
Practitioner Guidance
What to prioritise: Start by mapping which applications, vendors, and users legitimately depend on each public RPC endpoint or CDN. If you cannot name the business owner and expected traffic pattern, the service is not ready for a permanent exception.
What to verify: Confirm that your allowlist is tied to specific use cases, not broad domains alone. Validate that alerts cover the combination of network access, process creation, script execution, and download activity, because the abuse signal is usually the sequence, not the first request.
Common mistake: Treating public infrastructure as inherently hostile and blocking it wholesale. That approach often shifts risk rather than reducing it, because legitimate update and application traffic still has to flow somewhere.
Practitioner takeaway: The safest control is selective trust with strong telemetry, not categorical denial; if the service is needed, make it narrow, attributable, and monitored for unexpected follow-on execution.
Related resources from NHI Mgmt Group
- How should security teams stop text-only email fraud when there is no malware to block?
- What breaks when teams rely on manual review to stop script injection and malware delivery?
- How should security teams detect and stop malware delivery that hides a scheduled task inside a seemingly benign archive attachment?
- How should security teams stop sensitive data from being uploaded into public AI tools?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org