What are the risks of including email addresses as URL parameters?

9 Marketer opinions 4 Expert opinions 4 Technical articles 3 Resources

Summary

Including email addresses as URL parameters poses significant security and privacy risks. Experts and marketers alike strongly advise against this practice due to potential violations of Google Analytics' TOS, leakage of PII to various third parties (plugins, intermediary sites, trackers), and exposure through server logs, browser history, referrer headers, and even visual observation. This can lead to security vulnerabilities, privacy breaches, increased spam risk, and potential exploitation by malicious actors (e.g., unauthorized list unsubscriptions). Security documentation emphasizes mitigating techniques and adherence to best practices to protect sensitive data and prevent these exposures.

Key findings

Data Leakage: Email addresses in URLs leak to various third parties, including plugins, trackers, and intermediary sites.
Log Exposure: PII is exposed in server logs and browser history, creating a risk of unauthorized access.
Referrer Header Risks: Referrer headers leak sensitive data to other websites.
TOS Violation: Including PII in plain text violates Google Analytics' TOS.
Spam and Exploitation: Malicious actors can exploit exposed email addresses, e.g., for unauthorized unsubscriptions.
OWASP Concerns: OWASP highlights risks like exposure through shoulder surfing, increasing security vulnerabilities.
Spam Bots: Spam bots are able to find the URLS and sign up or unsubscribe users

Key considerations

Avoid Direct Inclusion: Avoid including email addresses as URL parameters whenever possible.
Use Hashing/Tokens: Employ hashing or tokens instead of directly passing PII.
Referrer Policy: Implement a strong Referrer-Policy to limit the information shared in referrer headers.
Log Management: Review and secure server logs to minimize data exposure.
Compliance: Ensure compliance with data protection regulations and platform TOS (e.g., Google Analytics).
Security Best Practices: Follow security best practices and OWASP guidelines to minimize the risk of data exposure and prevent vulnerabilities.
URL Security: Be aware of malicious bots that use URL and to make sure your website is secure from these.

What email marketers say
9Marketer opinions

Including email addresses as URL parameters poses significant security and privacy risks. This practice can expose sensitive data through various channels, including referrer headers, server logs, browser history, and third-party trackers. Bots crawling and indexing these URLs can lead to spam. Additionally, this practice violates company terms of service/privacy policies and increases the risk of phishing attacks.

Key opinions

Data Leakage: Email addresses in URLs can leak personal information through referrer headers, potentially exposing user data to third-party websites and analytics services.
Spam Risk: Including email addresses in URLs can lead to spam if bots crawl and index those URLs, resulting in unwanted communications.
Exposure in Logs: Email addresses included as URL parameters are stored in server logs and browser history, making them accessible to anyone with access.
Third-Party Tracking: Passing email addresses in query strings exposes this data to third-party trackers, compromising user privacy.
Phishing Risk: Including PII in URLs increases the risk of phishing attacks, as the exposed information can be used to craft targeted scams.
Policy Violation: Including PII in query strings is negligent and likely violates company terms of service and privacy policies.

Key considerations

Referrer Headers: Be mindful of referrer headers, as they can expose email addresses to third-party websites.
Server Logs: Avoid including email addresses in URLs to prevent their storage in server logs, limiting access to sensitive data.
Browser History: Consider the implications of email addresses being stored in browser history, which can compromise user privacy.
Data Security: Implement measures to prevent data leakage to third-party trackers and ensure compliance with data protection regulations.
Alternative Methods: Explore alternative methods for passing information, such as using hashed values or session tokens, instead of exposing email addresses directly.
Security Best Practices: Adhere to security best practices and OWASP guidelines to prevent information exposure through query strings in URLs.

Marketer view

Email marketer from StackExchange shares that including email addresses in URLs can lead to spam if bots crawl and index those URLs. Additionally, it can expose email addresses if the URL is shared or logged.

December 2023 - StackExchange

Marketer view

Email marketer from Information Security Forum explains that sending PII as URL parameters has the risk of exposing it in webserver logs, browser history, and the HTTP Referer header.

July 2021 - Information Security Forum

Marketer view

Marketer from Email Geeks explains that including PII in query strings is negligent and likely an issue with company terms of service/privacy policy.

October 2023 - Email Geeks

Marketer view

Marketer from Email Geeks explains this is a huge concern, OWASP details the risks, and recommends to NOT DO THIS.

August 2022 - Email Geeks

Marketer view

Email marketer from Reddit explains that including email addresses in URLs is bad practice as it will pass the email to any site the user clicks through and ends up in server logs.

October 2021 - Reddit

Marketer view

Email marketer from StackOverflow explains that using a url like `example.com/unsubscribe.php?email=email@example.com` puts this information in the server logs.

December 2021 - StackOverflow

Marketer view

Email marketer from InfoSec Exchange states that including PII in urls exposes the information to anyone who has access to the server logs, browser history, or shares the link. Also it increases the risk of a phishing attack

December 2021 - InfoSec Exchange

Marketer view

Email marketer from Troy Hunt's Blog explains that email addresses in URLs can leak personal information through referrer headers, potentially exposing user data to third-party websites and analytics services.

December 2023 - Troy Hunt's Blog

Marketer view

Email marketer from Medium explains that the risks of having personal data in the querystring include passing PII to 3rd party trackers, logging in plaintext, and exposing data via the browser history.

November 2021 - Medium

What the experts say
4Expert opinions

Including PII, particularly email addresses, as URL parameters poses several risks. It violates Google Analytics' Terms of Service, leaks email addresses to potential plugins, intermediary sites, server logs, and analytics tools. This exposure can lead to email addresses appearing in Google search results and creates opportunities for malicious actors to exploit the information, such as using the URL to unsubscribe users from lists without their consent, complicating spam tracking and causing user inconvenience.

Key opinions

TOS Violation: Putting PII in plain text violates Google Analytics' Terms of Service.
Data Leakage: Email addresses leak to potential plugins, intermediary sites, server logs, and analytics tools.
Search Engine Exposure: Email addresses can appear in Google search results due to inclusion in query strings.
Malicious Exploitation: Spammers can exploit email addresses in URLs to unsubscribe users from lists without their permission.
Spam Tracking: Using email addresses in URLs complicates the ability to track the source of spam.

Key considerations

GA Compliance: Ensure compliance with Google Analytics' Terms of Service by avoiding the inclusion of PII in plain text.
Data Security: Implement measures to prevent the leakage of email addresses to potential plugins, intermediary sites, and analytics tools.
Privacy Protection: Protect user privacy by avoiding the exposure of email addresses in Google search results.
URL security: Make sure urls are secure and cannot be used maliciously.
Alternative methods: Consider other methods to pass email addresses like hash or tokens.

Expert view

Expert from Email Geeks shares they have seen email address leaking into Google results from query strings in the past.

November 2024 - Email Geeks

Expert view

Expert from Word to the Wise explains that using PII in URLs is generally a bad idea and provides an example of a case where using an email address in a URL resulted in a spammer using the URL to unsubscribe a user from various lists, causing problems for the user and making it more difficult to track the source of the spam.

January 2023 - Word to the Wise

Expert view

Expert from Email Geeks explains that putting PII in plain text is a violation of Google Analytics' TOS and leaks the email to potential plugins or intermediary sites.

July 2024 - Email Geeks

Expert view

Expert from Email Geeks shares that including PII in email URLs is bad because it leaks email addresses into server logs and analytics tools.

August 2023 - Email Geeks

What the documentation says
4Technical articles

Including email addresses as URL parameters exposes sensitive information through multiple channels. OWASP highlights risks such as exposure via browser history, server logs, referrer headers, and even visual observation (shoulder surfing), leading to security vulnerabilities and privacy breaches. SANS Institute emphasizes that referrer headers leak personal data, recommending avoidance or control techniques. Mozilla reinforces this by explaining the Referer header's potential to expose previous page URLs with sensitive data, suggesting the use of a Referrer-Policy header. Veracode warns against storing sensitive data in URLs due to exposure in server logs and browser history, explicitly advising against storing PII in URL parameters.

Key findings

Data Exposure: Sensitive information in query strings can be exposed through browser history, server logs, referrer headers, and shoulder surfing.
Referrer Header Leakage: Referrer headers can leak sensitive information when URLs contain personal data.
Security Vulnerabilities: Exposure of sensitive data can lead to security vulnerabilities and privacy breaches.
PII Storage: Storing PII in URL parameters exposes it in server logs and browser history.

Key considerations

Avoidance: Avoid including sensitive data, such as email addresses, in URLs.
Referrer-Policy Header: Use a Referrer-Policy header to control what information is sent in the Referer header.
Mitigation Techniques: Use techniques to control or prevent the leakage of sensitive data through referrer headers.
Security Practices: Adhere to security best practices and guidelines to minimize the risk of data exposure.

Technical article

Documentation from Veracode explains that storing sensitive data in the URL can lead to security problems, such as exposing the data in server logs and browser history, and recommends to not store PII in url parameters.

January 2024 - Veracode

Technical article

Documentation from SANS Institute explains that referrer headers can leak sensitive information when URLs contain personal data. This can be mitigated by avoiding the inclusion of sensitive data in URLs or by using techniques to control the referrer header.

May 2021 - SANS Institute

Technical article

Documentation from Mozilla explains that the Referer header can expose the URL of the previous page, potentially leaking sensitive information if the URL contains personal data. This can be mitigated by using a Referrer-Policy header to control what information is sent in the Referer header.

July 2024 - Mozilla

Technical article

Documentation from OWASP explains that sensitive information in query strings can be exposed in several ways, including browser history, server logs, referrer headers, and shoulder surfing. This exposure can lead to security vulnerabilities and privacy breaches.

April 2024 - OWASP

Don't send along email as plain text in query paramater - Auth0 ...

We’re seeing plain-text email-addresses in query parameters of callback-urls, for example when a user has verified its email or changed its password. These email-addresses will end up in our logs, which we can’t do a lot about, and we don’t need them either. Could these be (optionally) removed please? It could potentially be a privacy risk.

Auth0 Community