0
No backend, no database, no network calls. I still found 3 security holes.
TL;DR: A single-file web tool exposed three security issues during a code audit: a loaded .json deck could leak user info when opened, potential prototype pollution via Object.assign and JSON.parse, and other path-based weaknesses. The article revisits how simple design choices can undermine privacy and security even without a backend.
The tool saves all deck data to a single .json file. Opening that file in a browser causes the app to fetch embedded images, leaking the opener's IP, user-agent, and timestamp. It relies on data URLs for images, but any file-derived string in the JSON can trigger extra network calls if not properly validated. The author stresses implementing an allowlist to block non-inline resources.
Additionally, a vulnerability exists around Object.assign combined with JSON.parse that can enable prototype pollution, illustrating how common JS patterns can introduce security risks in seemingly simple apps.
Question for the room: What low-risk pattern or guardrails have you added to similar front-end tools to prevent data-origin leaks and prototype pollution without adding back-end complexity?
— via dev.to
Add a comment
0/2000