CAPEC-148 Content Spoofing: How the Attack Pattern Works and How to Defend

Content spoofing is the attack where the message, page or file still looks like it came from you, but the words, links or code inside it are the adversary's. MITRE CAPEC catalogues it as CAPEC-148, a Meta-level pattern rated Medium for likelihood and Medium for severity, tied to CWE-345 (Insufficient Verification of Data Authenticity) and mapped to ATT&CK T1491 Defacement. Because it is a Meta pattern, it is less a single bug than a question every system has to answer: when a consumer receives content, how does it know the content is what the producer intended? This guide is for application security engineers, platform and web teams, and security architects. It sets out the forms the pattern takes, how to decide which integrity control fits each channel, how to detect tampering, and how to roll the controls out. For how CAPEC entries are structured, see the MITRE CAPEC Guide.

Key takeaways

• The apparent source never changes. CAPEC-148 is defined by content altered against the producer's intent while the origin, domain or sender stays the same, which is why users and machines trust it.
• There are two places to attack. Content can be changed at the source (the file, bucket, CMS or template) or in transit (between producer and consumer), and each needs a different control.
• Authentication of the server is not authentication of the content. TLS proves who served the bytes; it does not prove a third-party script or a stored file is the version you approved. Hashes and signatures do.
• Text injection survives XSS defences. OWASP notes that spoofed text needs no script, so output encoding alone does not stop a fake notice or a changed figure on a trusted page.
• Write access is the real perimeter. Most source-side spoofing is a write permission that should not exist, often held by a machine identity, so access to publishing paths deserves the same review as access to production data.

How the attack pattern works

CAPEC-148 describes an adversary who modifies content so it contains something other than what the original producer intended, while keeping the apparent source unchanged. The term is most often used for web pages, but the entry is explicit that any content can be spoofed, including email messages, file transfers and other network protocols. Sometimes the adversary hides the change; with a defacement, hiding it is not the point.

The CAPEC prerequisites are short: the target provides content but does not adequately protect it against modification, the adversary has a means to alter data they are not authorised to change, and for in-transit variants the adversary can intercept the messages. The resources noted are an interception tool for in-transit attacks, or, in variants where page elements are pointed at attacker-hosted images or frames, somewhere to host the replacement content. The single listed consequence is integrity: modified data. The CAPEC entry lists no mitigations of its own, so the controls below come from the related weakness, standards and platform guidance.

The outcomes CAPEC names are malware exposure, financial fraud where the content governs transactions, and privacy violations. In practice that means a fake login form on a genuine domain, changed bank details in a genuine supplier email thread, a tampered script served from a genuine CDN path, or an altered price, recommendation or instruction on a page users have every reason to trust.

The family: children and related patterns

CAPEC-148 has no parent. Its children and neighbours show how wide the meta pattern runs, and most of them already have a deeper NHI Mgmt Group guide.

CAPEC also lists CAPEC-148 as able to follow HTTP request splitting, HTTP response smuggling and the KNOB Bluetooth key negotiation attack, which all give an adversary a position to alter what a consumer receives. CWE-345 is a Class-level weakness that MITRE marks as discouraged for vulnerability mapping because it is abstract; its children are where root causes are recorded, for example CWE-347 (Improper Verification of Cryptographic Signature), CWE-354 (Improper Validation of Integrity Check Value), CWE-494 (Download of Code Without Integrity Check) and CWE-924 (Improper Enforcement of Message Integrity During Transmission in a Communication Channel).

Where content spoofing shows up

Web pages: reflected text and HTML injection

OWASP describes content spoofing (also called content injection or virtual defacement) as an injection flaw where user input is reflected into a page so that a modified page appears under the trusted domain, usually combined with a crafted link. It distinguishes two forms. In HTML injection, unencoded markup is rendered, and the OWASP example injects a fake login form that posts credentials elsewhere. In text injection, output is encoded, so nothing executes, but the displayed text is still altered, for example turning a "buy" recommendation into "sell" or adding a notice that sends users to another site. OWASP also describes an email variant: user-supplied text such as a project name placed into an automated email, where the mail client turns domain-like text into a clickable link even though HTML was escaped. Script-based injection is covered in the Cross-Site Scripting (XSS) Prevention Guide; this guide focuses on what remains once script is blocked.

Hosted files, scripts and buckets: source-side tampering

When an adversary can write to the place content is published from, every consumer receives the spoofed version from the genuine origin. ATT&CK T1491 Defacement (with T1491.001 Internal Defacement and T1491.002 External Defacement) covers the visible end of this. The quieter end is a changed script or download. A typical case is a storage bucket policy left world-writable after troubleshooting, which lets an outsider replace a hosted JavaScript library with a version that redirects visitors' browsers. No credentials need to be stolen, and the lesson is that write access to a distribution path is an identity decision.

Email and business messages

A supplier email thread with altered bank details, or a genuine notification template carrying injected text, is content spoofing even when the sending domain is real. Sender authentication (SPF, DKIM, DMARC) proves the domain; DKIM signing also protects the signed headers and body in transit, but neither helps when the genuine mailbox or template itself is the thing being abused. See the DMARC, SPF and DKIM Guide and the Business Email Compromise Response Playbook.

Mobile inter-app messages

Android's guidance on implicit intent hijacking explains that an intent without a fully qualified component or package can be intercepted by any app that registers a matching intent filter, which may then read or modify sensitive data, act on mutable PendingIntents or Binders, or launch attacker-controlled components. The fix it gives is to call setPackage() so only the intended component handles the intent, and, where an implicit intent is unavoidable, to leave sensitive data and mutable objects out of it. See the Android App Security Guide.

In-transit modification

ATT&CK T1565.002 Transmitted Data Manipulation and T1557 Adversary-in-the-Middle describe the network side. RFC 6797 (HTTP Strict Transport Security, Standards Track, November 2012) lists active network attackers who impersonate DNS servers or run rogue access points among the threats it addresses, and has conformant browsers upgrade insecure references to HTTPS and refuse click-through on certificate errors. It also states plainly that HSTS does not address phishing or malware. See the MITRE ATT&CK T1557 Adversary-in-the-Middle guide and the HSTS and HSTS Preload guide.

Choosing the right integrity control

The decision turns on two questions: where can the content be changed, and can the consumer check a value the adversary cannot recompute? CAPEC-145 makes the second point directly: a plain checksum sent alongside the message can be recalculated by whoever alters the message, whereas a cryptographic check keyed with a secret known only to sender and receiver prevents it.

Small organisations: get the high-yield controls first: HSTS on every site, SRI on every static third-party script, least-privilege write access to web roots and buckets, and DMARC moving to enforcement. Large organisations: add signed artefacts end to end, message signing for partner APIs, file integrity monitoring on publishing paths, and a register of every external content source a page loads.

On text injection, OWASP's advice is to find user input reflected in responses, encode output properly and make user-supplied content visually distinct from trusted content. NHI Mgmt Group adds one design rule: where a page reflects input into a trusted message (an error, a confirmation, a notification email), use a fixed message from a list keyed by a code rather than echoing the input at all.

Where identity fits

Source-side content spoofing almost always runs through a write permission. The identities that hold write access to web roots, storage buckets, CDN origins, package registries and email templates are mostly non-human: deployment pipelines, CMS service accounts, build agents and integration tokens. A token with standing write access to a publishing path is a ready-made content spoofing capability for anyone who obtains it.

• Scope: give each pipeline its own identity with write access to its own path only, and deny writes from every other principal at the resource policy.
• Lifetime: use short-lived federated credentials for publishing jobs rather than long-lived keys. See the Secrets Management Guide.
• Temporary grants: any write permission added for troubleshooting needs an owner and an expiry. Our recommendation is a maximum of 24 hours, with automatic reversion.
• Review: include publishing paths in access reviews alongside production data stores.

Implementation approach

1. Inventory content sources (weeks 1 to 2): list every site, bucket, CDN origin, download location, email template and API that produces content others trust, and every external script each page loads.
2. Map writers: for each source, list every human and machine identity with write access. Remove wildcard principals and stale grants first; this is usually the fastest risk reduction.
3. Close the transit gap: enforce HTTPS with HSTS across all hosts, starting with a short max-age and raising it once no mixed content remains; includeSubDomains only after every subdomain is ready.
4. Add content integrity: SRI on static third-party resources with SHA-384 (the W3C draft's suggested baseline), signature verification for downloads and artefacts, message signing for partner APIs.
5. Fix reflection: test every parameter that is echoed into pages and emails, apply output encoding, and replace echoed text in trusted messages with fixed messages.
6. Test before enforcing: run Content Security Policy in report-only mode and review violations; trial SRI on a staging build so a hash mismatch does not take a page down in production.
7. Roll back safely: keep the previous known-good version of every published file and the previous header configuration, so a broken SRI hash or HSTS setting can be reverted within minutes. For HSTS, a max-age of zero removes the policy for browsers that receive it, which is why the first value should be short.

Detection and measurement

ATT&CK's detection strategy for T1491 (DET0238) points at unauthorised file changes and script injections in web or application content, shell access or script uploads to web servers, manipulated application bundles and server configuration, changes on mounted static content paths, and cloud storage content altered with compromised instance credentials. Turn those into concrete signals:

• File integrity: alerts on any change to web roots and publishing buckets outside a deployment window or not made by the deployment identity. See the File Integrity Monitoring Guide.
• Policy changes: alerts when a bucket or container policy gains public or wildcard write access.
• Browser reports: CSP violation reports and SRI failures (the W3C draft says the browser fires an error event on a failed check, which a page can log).
• External monitoring: scheduled fetches of key pages and hosted scripts compared against a known-good hash.
• Email: DMARC aggregate reports and DKIM failures for your domains.

Framework mapping

Common failure patterns

• Trusting TLS for content: assuming HTTPS from a CDN means the script is the approved one. TLS authenticates the server, not the file.
• Checksums beside the download: publishing a hash on the same site as the file, so whoever replaces one replaces both.
• Encoding and stopping there: output encoding blocks markup but leaves text injection, so error pages still say whatever the link tells them to.
• Troubleshooting grants that never expire: a write permission added temporarily and left in place.
• SRI on some pages only: a single unprotected page loading the same third-party script is enough for an attacker who controls that script.
• No known-good copy: without versioned, protected backups of published content, recovery from defacement becomes a rebuild. See the Website Defacement Playbook.

Practitioner checklist

• Inventory every content source and every external script your pages load.
• List every identity with write access to publishing paths and remove wildcard and stale grants.
• Give each publishing pipeline its own short-lived, path-scoped identity.
• Enforce HTTPS with HSTS on all production hosts.
• Add SRI with crossorigin to static third-party scripts and stylesheets. See the Subresource Integrity (SRI) Guide.
• Verify signatures on downloads and build artefacts; publish hashes away from the files they describe.
• Test all reflected parameters in pages and emails; replace echoed text in trusted messages with fixed messages.
• Monitor file and policy changes on publishing paths, and collect CSP and SRI failure reports.
• Keep protected, versioned known-good copies of published content for fast restore.

Standards and references

• MITRE CAPEC: CAPEC-148 Content Spoofing
• MITRE CAPEC: CAPEC-145 Checksum Spoofing
• MITRE CWE: CWE-345 Insufficient Verification of Data Authenticity
• MITRE ATT&CK: T1491 Defacement
• OWASP: Content Spoofing
• W3C: Subresource Integrity
• IETF: RFC 6797 HTTP Strict Transport Security (HSTS)
• IETF: RFC 6376 DomainKeys Identified Mail (DKIM) Signatures
• Android Developers: Implicit intent hijacking

Related NHI Mgmt Group resources: MITRE CAPEC Guide, Content Security Policy Guide, Typosquatting and Lookalike Domains Guide, Web Cache Poisoning and Cache Deception Guide.