{
  "id": 17915967,
  "title": "Attachments you should refuse before they reach the parser",
  "url": "https://urgent.news/2026/11/03/attachments-you-should-refuse-before-they-reach-the-parser",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-11-03T05:39:43.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/volanea/attachments-you-should-refuse-before-they-reach-the-parser-2oe7"
  },
  "original_language": "en",
  "account": "Attachments that should be refused before they reach the parser are crucial to maintaining system security. Running a parser on bytes from an unknown source poses risks, so it is essential to implement cheap defenses at the boundary. Extension and content-type allowlists, size caps, and a hard limit on the number of parts are effective initial safeguards. However, trust the decoded bytes, not the header, as the Content-Type header is simply a claim. After decoding, check the magic bytes to verify the file type. For example, a file named invoice.pdf starting with PK is likely a zip, and a file named photo.jpg starting with MZ is probably a Windows executable. Both types of files should be rejected before any further inspection.\n\nThe zip bomb is a particularly insidious threat. A single attachment can expand from kilobytes to gigabytes when decompressed, potentially filling a container's disk space if not capped. Therefore, any archives decompressed should have both a cap on the decompressed size and a cap on the file count, with decompression halted immediately upon exceeding either limit. Decompressing into a temporary directory without such caps leaves systems vulnerable to disk filling.\n\nEncrypted archives and macro documents present additional dangers. A password-protected zip file cannot be scanned and is specifically designed to evade detection. It should either be rejected or quarantined for manual review. Office documents with macros are equally risky and should receive the same treatment. A key operational detail is to scan attachments asynchronously but deliver the message synchronously, accompanied by a quarantine flag. Blocking the inbound webhook on a virus scan can lead to timeouts, as the sender will retry, resulting in duplicate messages. Volanea mitigates these risks by enforcing size and part-count limits at the API boundary. Attachments are returned as URLs, ensuring that scanning occurs after the message has been safely stored, maintaining system integrity while preventing potential security breaches.",
  "summary": "Accepting any attachment is a decision to run a parser on bytes a stranger chose. The cheap defences are at the boundary: extension and content-type allowlists, size caps, and a hard limit on the number of parts. Trust the decoded bytes, not the header The Content-Type header is a claim. Check the magic bytes after decoding: a file named invoice.pdf that starts with PK is a zip, and a file named…",
  "key_points": [
    "Refuse attachments from unknown sources to prevent security risks.",
    "Trust decoded bytes, not header claims, for accurate file type verification.",
    "Enforce caps on decompressed size and file count for archives to avoid disk filling."
  ],
  "editors_take": "Implementing strict boundary defenses and asynchronous scanning protects system integrity by neutralizing malicious files before they can exploit parser vulnerabilities or exhaust critical disk resources.",
  "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."
}