Preventing email header injection in contact forms.
Forms do not accept freely entered headers; recipient and subject are derived from predefined rules, and addresses are strictly validated.
PHP developers and website operators can check for "preventing email header injection" at three specific points: "Fixed destination addresses," "Strict header field," and "Free From value."
Published: 3 min read · Author: Sebastian Geier
How does a PHP contact form prevent injected additional email headers?
User values must never be directly entered into the To, Cc, Bcc, or raw header fields. A reply contact is validated as a single address and checked for CR and LF, while fixed sender and recipient addresses are defined in the configuration; the library handles correct encoding and transmission.
Use Case: "Free From Value"
A form sets the entered email address in the From field using string concatenation. The implementation switches to a fixed domain sender and validated Reply-To via a mail library; attempts with encoded Bcc line breaks are discarded before sending.
Strict Header Field
Identify all request values that can currently influence the recipient, From, Reply-To, subject, or other headers.
Configure destinations and senders statically, strictly validate individual address fields, and reject CR and LF before transmission.
Switch sending to a maintained library and run tests with encoded line breaks, multiple addresses, and long values.
Free From Value
Free From Value – The form address is used as the raw sender address and allows additional headers or fails due to sending policies.
Line Break Bypass – Incomplete filters only recognize CR and LF representations, while decoding or multiple values later create new headers.
Message as Header – Subject or free text is written into the header structure via concatenation and does not cleanly separate content from metadata.
Fixed Destination Addresses
Fixed Destination Addresses – Recipient and technical From value originate from a protected configuration and cannot be influenced via request fields.
Strict Header Field – An optional Reply-To field is checked as having exactly one valid address and rejects all CR or LF characters.
Library-based sending – A well-maintained mail component generates headers and MIME structures instead of manually generated strings with unclear escaping.
Library-based sending
Number of user-configurable header fields and percentage of sending paths with fixed recipients and library-based encoding.
Rejected address values with line breaks, multiple destinations, or invalid formats without generating a message.
How "Preventing Email Header Injection" relates to other topics
Separates "Preventing Email Header Injection" Mastering Relative and Absolute Paths in Nested Projects an important follow-up question: How do you prevent PHP includes in nested directories from suddenly using incorrect paths?
Those who want to delve deeper into "Preventing Email Header Injection" from the perspective of the "Hosting, Server, CDN & Caching" cluster will find further information in Securely set up reverse proxies for internal services .
If you want to practically implement "Preventing Email Header Injection," you can refer to Robust Website Systems This focuses on "Form Input and Secure Processing" and "Fixed Destination Addresses."
Conclusion: Preventing Email Header Injection
Header injection is prevented at the trust boundary, not through subsequent text manipulation. Fixed targets, strictly defined individual addresses, and a mail library keep user data out of the structure.
Sources and Further Information
These primary sources are authoritative for platform behavior, terminology, and validation limits regarding "preventing email header injection."
Input Validation Cheat Sheet — OWASPOWASP recommends context-aware allowlisting rules, length limits, and server-side validation for untrusted input.
mail — PHP ManualThe PHP manual explicitly warns against including unverified external data in additional mail headers.
RFC 5322: Internet Message FormatThe IETF standard defines the structure, fields, and line boundaries of Internet messages, and thus the structure that header injection can exploit.
Key Thesis
User input is never directly converted to To, Cc, Bcc, or other header lines. A well-maintained mail library sets fixed recipients and encodes content; sender addresses are validated, and CR/LF in header fields are rejected.
What This Is Not About
Removing individual line breaks from the message body does not protect headers if user input still determines recipients, senders, or additional headers.
What it's about
Recipients and header structure remain fixed on the server side; a well-maintained mail library encodes validated addresses and treats the message body solely as content.
PHP, forms & security
Normalize input without corrupting legitimate characters
"Preventing Email Header Injection" includes, as a separate test step, the question: How does PHP normalize text input without corrupting names, accents, or punctuation?
PHP, forms & security
Building a Security and Error Log for Production Forms
"Preventing Email Header Injection" is supplemented by a separate decision: Which form events should be logged without creating new data privacy or security risks?
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Strict header field: Focus of the next test
In the current sending code, every concatenation of request values in headers should be marked. These instances will be replaced by fixed configuration or typed library methods and tested with CR/LF payloads.