Claude Code Security and Magecart: Getting the Threat Model Right

When malicious Magecart code hides in the EXIF metadata of a favicon image loaded dynamically from an external source, no repository scanner will catch it. The code never reaches the repository — it exists only in the user's browser memory at the moment of execution. This is not by accident, but a precisely planned gap in our threat model. As adoption of tools like Claude Code Security for static code analysis grows, we must clearly define where AI-assisted code scanning security ends and where client-side execution security begins.

The problem is not new, but it has become more urgent. Teams invest in advanced static analysis tools, implement DevSecOps best practices, and feel secure — until it turns out that the threat came from a completely different direction. Magecart, a network of attacks targeting e-commerce, has for years demonstrated that the simplest attack vectors can be the most effective. And when we combine this with dynamic loading of third-party resources, we get a combination that traditional security tools ignore.

Anatomy of a Magecart attack — how a real threat scenario works

Magecart is not a specific group of hackers, but an ecosystem of cybercrime focused on stealing credit card data from e-commerce sites. Their method of operation is elegant in its simplicity: instead of attacking the shopping platform directly, they inject JavaScript code into third parties — libraries, plugins, analytics scripts — that are already integrated with thousands of websites. When a user visits a store, their browser downloads the script from the infected server, and the malicious code takes control of the payment form.

The variant we're interested in here is even more sophisticated. Instead of placing JavaScript code directly in the script, attackers hide it in the EXIF metadata of an image file — typically in the comment field or GPS data. The favicon file (the small icon displayed in the browser tab) is loaded dynamically, meaning it is not included in the code repository or appears in any resource controlled by the team. The server delivers the image, the browser processes it, and if JavaScript code is embedded in the metadata, some JavaScript libraries can extract and execute it.

Here's the key point: no static scanner can detect this. Not because the tools are weak, but because the threat does not exist in static code. It exists in a dynamically loaded binary resource, processed by the browser in real time. Claude Code Security, like SAST (Static Application Security Testing), scans source code. It does not scan images downloaded from CDNs during application execution.

The limits of Claude Code Security — where AI-assisted analysis actually works

Claude Code Security is an advanced static code analysis tool that leverages the capabilities of Anthropic's language models to identify security vulnerabilities. It works by scanning source code, analyzing execution paths, and detecting known threat patterns — SQL injection, cross-site scripting (XSS), authorization issues, vulnerable dependencies.

The tool is particularly good at:

• Identifying logical security errors — when a developer forgets to check user permissions before accessing a resource
• Detecting known CVEs — when code uses a library containing a known vulnerability
• Analyzing data flow — tracking how data moves through an application and whether it can be exploited for an attack
• Reviewing coding patterns — detecting insecure practices such as hardcoding passwords or lack of input validation

But Claude Code Security — and every other SAST tool — cannot analyze dynamic resources. It cannot know what an API endpoint will return in a production environment. It cannot monitor what images a browser downloads. It cannot execute JavaScript code in a browser context and observe what changes it makes to the DOM. These are tasks for DAST (Dynamic Application Security Testing) tools and runtime security monitoring.

Dynamic loading of third parties — a weak point in the chain of trust

Most modern web applications rely on resources from external sources. CDNs deliver images, analytics services deliver scripts, payment platforms deliver form components. Each of these sources is a potential attack vector. If an attacker takes control of any of them — through server compromise, man-in-the-middle attack, or DNS manipulation — they can inject malicious code into every website that downloads a resource from that source.

Dynamic loading complicates defense. In a traditional application, all resources are bundled during build and deployment. The security team can scan every file. But when resources are fetched at runtime — favicon from one CDN, analytics script from another, font from a third — the scanning process must be continuous. Every downloaded file must be monitored, its integrity verified, and checked for known threats.

Magecart understands this perfectly. Instead of attacking the code repository (which has backups, version control, access audits), they attack the infrastructure that delivers runtime resources. Instead of injecting JavaScript code (which would be easy to notice), they inject it into image metadata (which browsers process without particular oversight).

EXIF metadata as an attack vector — why images are not what they seem

EXIF (Exchangeable Image File Format) is a standard for storing metadata in image files. It was designed for cameras and contains information such as the date a photo was taken, camera settings, and GPS location. But EXIF is just a data structure — you can put practically anything in it.

Most web browsers do not process EXIF metadata — they simply display the image. But JavaScript running in a browser can read metadata if the image is loaded as a byte array instead of being displayed directly. Libraries such as piexifjs or exifjs allow easy extraction of metadata from an image. If a developer accidentally (or intentionally, in the case of infected code) uses such a library to process a favicon image, malicious code embedded in the metadata can be extracted and executed.

This is particularly dangerous because:

• The favicon is loaded automatically — the browser downloads it without an explicit request from the page
• It is not scanned by security tools — most scanners focus on code and dependencies, not images
• It can come from any source — the favicon can be loaded from a different domain, CDN, or even generated dynamically
• Changing metadata does not change the appearance of the image — attackers can modify metadata without affecting favicon functionality

A gap in the threat model — what Claude Code Security cannot see

A threat model is a document describing what threats can affect a system and what defense mechanisms are in place against them. A good threat model should cover attacks at every level: in source code, in dependencies, in infrastructure, at runtime, in the client browser.

The problem is that Claude Code Security and similar SAST tools are typically deployed as part of the CI/CD process — they scan code before deployment. They cannot monitor what happens after deployment. When a favicon is loaded from a CDN, Claude Code Security does not know that the CDN has been compromised. When a browser processes EXIF metadata, Claude Code Security does not know that the metadata contains malicious code.

This is not the tool's fault — it is a natural boundary between static analysis and runtime security. But it means that teams relying solely on Claude Code Security and similar tools have a false sense of security. They think their code is secure because the scanner found no vulnerabilities. But the Magecart threat is not in the code — it is in a dynamically loaded resource that no static scanner will ever scan.

Real threats to Polish e-commerce — where Magecart appears

Poland has a dynamically developing e-commerce sector. Platforms such as Allegro, OLX, Vinted, and hundreds of smaller online stores handle millions of transactions annually. Each of those transactions is a potential target for Magecart.

Polish e-commerce stores are particularly vulnerable to Magecart attacks because:

• They often use open-source plugins — WooCommerce, PrestaShop, Magento — that integrate third parties
• They have limited security resources — small and medium-sized stores cannot afford a dedicated security team
• Polish credit cards are valuable on the black market — attackers deliberately target the Polish segment because card data can be sold for a good price
• There is a lack of awareness about such threats — most e-commerce developers know about XSS and SQL injection, but do not know how Magecart hides code in image metadata

Known cases of Magecart attacks on Polish websites include compromised payment plugins, infected JavaScript libraries from Polish CDNs, and modified favicons from infected hosting servers. In each case, the code never reached the repository — it existed only in dynamic resources.

Building defense beyond static analysis — zero trust architecture for runtime

If Claude Code Security cannot protect against Magecart attacks, what should teams do? The answer lies in Zero Trust architecture — an approach that assumes every resource, every connection, every user can be a threat and must be verified.

In the context of Magecart threats, Zero Trust architecture should include:

• Content Security Policy (CSP) — restricting what resources the browser can load and from which sources
• Subresource Integrity (SRI) — verifying that downloaded resources (scripts, images) have not been modified
• Runtime monitoring — observing what resources are loaded, what changes are made to the DOM, what network requests are sent
• Sandboxing third-party resources — isolating third-party scripts in an iframe with limited permissions
• Verification of resource integrity — downloading resources from multiple sources and comparing whether the content matches

Content Security Policy is particularly important. A CSP policy can specify that scripts can only be loaded from specified domains, that images can come from specific CDNs, that connections can only be made to approved servers. If an attacker tries to infect a favicon and extract JavaScript code from it, CSP can block the execution of that code because it comes from an unapproved source.

Subresource Integrity allows you to specify what the hash (checksum) of a resource should be. The browser compares the downloaded resource with the expected hash. If the resources do not match — because the CDN has been compromised and the content changed — the browser will not load the resource. This prevents Magecart from changing favicon content without detection.

Integrating Claude Code Security into a complete security stack

It is not that Claude Code Security is useless — it is a valuable tool. The point is that it must be part of a larger defense system, not the only layer of security.

An effective security stack for an e-commerce application should include:

• SAST (Static Application Security Testing) — Claude Code Security, SonarQube, Checkmarx — scanning code before deployment
• DAST (Dynamic Application Security Testing) — Burp Suite, OWASP ZAP — testing the application at runtime
• Runtime security monitoring — observing application behavior in production, detecting anomalies
• Dependency scanning — monitoring whether dependencies contain known CVEs
• Infrastructure security — securing servers, databases, CDNs
• Browser security — CSP, SRI, sandboxing, DOM monitoring

Claude Code Security is responsible for the first layer — static code analysis. But without the remaining layers, the team has a false sense of security. Magecart attackers are not interested in code — they are interested in dynamically loaded resources, infrastructure, the client browser. These areas require different tools, different processes, a different approach.

Conclusion — the threat model must be accurate for defense to be effective

Claude Code Security is a powerful tool, but its limits are clear. It scans static code. It does not scan dynamic resources, does not monitor runtime, does not protect the client browser. Magecart attacks, which hide code in EXIF metadata of dynamically loaded images, are outside the scope of SAST tools.

For teams implementing Claude Code Security, the lesson is simple: do not treat SAST tools as a complete security solution. Treat them as one layer in a multi-layered defense. Define a threat model that covers attacks at every level — code, dependencies, infrastructure, runtime, browser. For each threat, choose the appropriate tool and process. Claude Code Security protects code. CSP and SRI protect the browser. Runtime monitoring protects production. Together they create a defense that is truly effective.

Magecart will attack as long as e-commerce and credit cards exist. But if the threat model is accurate and the defense is multi-layered, attackers will be forced to look for easier targets.