fix(security): validate decompressed file size to prevent ZIP bomb attacks

[anshul23102]

Summary

This PR fixes the ZIP bomb vulnerability by validating decompressed file sizes instead of relying on spoofable compressed metadata. The endpoint now safely handles malicious ZIP files that claim small size but expand to gigabytes.

Problem

The analyze_zip endpoint checked file size from the ZIP central directory header (info.file_size) BEFORE decompression. Attackers can forge this header to report tiny sizes while the actual decompressed data is gigabytes, causing:

• Out-of-memory crashes
• Resource exhaustion / DoS
• Service unavailability

Solution

1. Decompression-first validation - check actual decompressed size AFTER archive.read()
2. Per-file limit - enforce 2MB maximum per extracted file
3. Cumulative limit - track and enforce 5MB total across all files
4. Early abort - reject ZIP immediately if any file exceeds limits
5. Real-world safe - prevents gigabyte-scale expansions within milliseconds

Changes

• backend/app/routers/analyze.py:
  • Move file size check to after archive.read(info)
  • Use len(raw) (actual decompressed size) instead of info.file_size
  • Add MAX_PER_FILE_BYTES (2MB) constant
  • Check both per-file and cumulative limits

Security Impact

• Prevents ZIP bomb attacks from bypassing size restrictions
• Eliminates false sense of security from header validation
• Protects service from resource exhaustion attacks

Testing

• Normal ZIP files with legitimate sizes work correctly
• ZIP files with spoofed small headers are rejected
• Per-file limit prevents extraction of giant single files
• Cumulative limit catches multiple moderately-sized files
• Error messages are helpful for debugging

Related Issue

Closes #710

---

This contribution is part of GSSoC 2026. Please consider adding the gssoc-approved label when reviewed.