{
  "id": 10361820,
  "title": "'No tools listed' should mean deny, not allow-all",
  "url": "https://urgent.news/2026/09/28/no-tools-listed-should-mean-deny-not-allow-all",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-28T04:08:41.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/rojaneerdev/no-tools-listed-should-mean-deny-not-allow-all-9e7"
  },
  "original_language": "en",
  "account": "A significant configuration bug has surfaced in numerous systems, causing widespread concern. In many frameworks, an empty or absent list does not signify a lack of access; instead, it permits unrestricted access. This vulnerability, known as privilege by omission, enables maximum access granted not by an intentional decision but by the absence of a specific directive.\n\nThe issue is pervasive, with instances ranging from service permissions to firewalls and Kubernetes configurations. The danger lies in the fact that no one explicitly allows everything; it is simply the system's default behavior when no guidelines are provided. This can occur due to code refactoring, missing entries, or configuration errors. Regardless of the source, the result is often an unintentional wide-open access that goes unnoticed until it causes significant problems.\n\nIn contrast, a deny-by-default approach would lead to a different outcome. If someone accidentally omits a rule, the system would deny access by default, making the mistake immediately apparent during review. This approach prevents silent failures and ensures that only explicitly allowed access is granted, minimizing the risk of security breaches and unauthorized activity.\n\nTo address this issue, a simple yet effective rule should be applied: name your capabilities explicitly or be rejected. The widest access should be represented by an explicit marker, such as a [ * ] or \"mode: all,\" rather than relying on default configurations. Additionally, the absence of any capabilities should be treated as an error and rejected during the loading process, prompting the user to correct the issue.\n\nBy implementing this \"no privilege by omission\" rule, organizations can prevent configuration errors from silently granting excessive permissions and protect their systems from potential security vulnerabilities. This approach emphasizes the importance of explicitly defining capabilities and rejecting the default \"allow all\" scenario, ensuring that only intentional and appropriate access is granted.",
  "summary": "Here's a config bug that has shipped in more systems than anyone would like to admit: # grant this service access to... nothing? everything? allowedOrigins : [] In a surprising number of frameworks, an empty or missing list doesn't mean \"no access.\" It means all access . Empty CORS origins → reflect any origin. A Kubernetes pod with no NetworkPolicy selecting it → all traffic allowed. A firewall…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}