Bright is expanding test coverage with a new check for EXIF Metadata Leakage. The check determines whether a web application preserves sensitive EXIF metadata after a user uploads an image and the application later serves that image back through a URL, API response, or rendered page. Instead of flagging only a potentially unsafe storage configuration, the scanner validates the full processing path: upload endpoint, application response, image discovery, retrieval, and metadata extraction. This allows it to identify confirmed leakage in the way the application actually handles user-supplied media.
EXIF metadata can contain much more than basic technical information about a photo. GPS coordinates can reveal where an image was taken, timestamps can connect the image to a person’s movements or routines, and fields such as camera make, model, lens model, author, description, or comments can expose information about the device or owner. Even when the visible image content appears harmless, retained metadata can make a user or organization vulnerable to tracking, doxing, or targeted social engineering. This maps to CWE-1230: Exposure of Sensitive Information Through Metadata, where access to the original resource may be restricted, but derived metadata still discloses sensitive information.
This issue commonly appears in applications that handle avatars, marketplace listings, classified ads, content management workflows, social features, and internal enterprise portals. Client-side EXIF stripping is not a reliable security boundary: an attacker can construct API requests directly, bypass the browser UI, or upload original files through an integration path. Robust mitigation belongs on the server side. Applications should decode the image, create a new bitmap, and re-encode the output, or apply a strict allowlist policy for only the metadata fields that are explicitly required before storing or publishing the file.
Bright’s new check actively tests suitable multipart and JSON upload flows using unique JPEG and PNG canary images. Each canary contains controlled metadata values in fields such as UserComment, ImageDescription, Artist, timestamp fields, and GPS coordinates. Every upload uses fresh randomized markers, so the scanner does not rely on generic signatures, cache artifacts, or assumptions about a specific media pipeline implementation.
After the upload, Bright engine searches for the actually published version of the image. It inspects the response body, redirect headers, JSON and HTML responses, image links, and the rendered DOM. To preserve the authorization context, the check follows only same-origin locations and safely retrieves discovered images. It then extracts metadata and compares the result against the original canary. A finding is created only when a relevant metadata field matches exactly, or when a verified GPS coordinate pair is preserved. The scanner does not treat a random marker appearing somewhere in the file bytes as sufficient evidence.
This approach reduces false positives and gives security teams reproducible proof: the original upload request, the application response, the specific EXIF fields that were retained, and the URL where the image was found. If the application re-encodes the image and removes metadata, no finding is reported. If metadata is preserved, the team gets a concrete remediation scenario and can enforce server-side stripping as a testable AppSec control in CI/CD, instead of relying on manual audits of file storage or media processing behavior.
Related materials
- CWE-1230: Exposure of Sensitive Information Through Metadata
Describes the weakness class where sensitive information is exposed through metadata derived from a protected or semi-protected resource. Relevant for EXIF leakage because the visible image may be acceptable to publish while embedded metadata still exposes private information.
https://cwe.mitre.org/data/definitions/1230.html - OWASP File Upload Cheat Sheet
Provides practical guidance for secure file upload handling. Relevant because image upload pipelines should validate files and, for images, use rewriting/re-encoding techniques that can strip unwanted embedded content and metadata.
https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html - CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
A broader information-disclosure weakness category. Relevant as a parent/contextual CWE for cases where preserved metadata exposes sensitive information to users who should not receive it.
https://cwe.mitre.org/data/definitions/200.html
