T09 · Insecure Skill Coding Practices
- Location
SKILL.md:258- Finding
Recipient Email Addresses Exposed in Registration URL Query Parameters
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 258–267
Vulnerability Type: Personal data exposure through URL query parameters
Risk Level: MediumComplete Code Snippet:
html ### Required Template Variables ```html <!-- Email parameter for personalized links --> <a href="https://www.ainative.studio/register?gift={{campaign_id}}&email={{email}}"> Claim Your Trial </a>text The associated sending workflow replaces `{{email}}` with the recipient's actual email address before delivery: ```python # Replace template variables html = template_html.replace("{{email}}", email) html = html.replace("{{campaign_id}}", campaign_id)Technical Analysis
The campaign template places a recipient's email address directly in a URL query parameter. Because the sending function substitutes
{{email}}with the actual address, the delivered link contains plaintext personally identifiable information.Query strings can be retained or exposed through:
- Browser history and synchronized browser data
- Web server, reverse-proxy, CDN, firewall, and monitoring logs
- Analytics and observability platforms
- Screenshots, copied links, and forwarded messages
- Referrer headers when the registration page loads third-party or cross-origin resources, subject to the effective referrer policy
The email value is also controlled by the client after delivery. A recipient can edit the query parameter before opening the registration page. If the backend relies on this value for identity, trial activation, conversion attribution, or authorization without independent validation, an attacker could cause incorrect attribution or attempt to associate campaign actions with another address.
Sending a recipient address to the declared email provider is necessary for email delivery, but including that address in a registration URL is not the minimum disclosure required for campaign attribution.
A
...[truncated 1478 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace the plaintext
emailquery parameter with a cryptographically random, opaque, single-use campaign token. - Store only the necessary server-side association between the token, campaign, and intended recipient.
- Give each token a short expiration time and invalidate it after successful use.
- Alternatively, use a signed token that is integrity-protected, time-limited, audience-bound, and free of plaintext PII.
- Validate campaign and recipient associations exclusively on the server. Never treat a client-controlled email parameter as proof of identity or authorization.
- Prevent token replay and require normal account verification before activating a trial or modifying a subscription.
- Remove or redact email-bearing query strings from application, proxy, CDN, analytics, and observability logs.
- Configure a restrictive
Referrer-Policy, such asno-referrer, on registration and campaign landing pages. - Review historical logs and analytics stores for previously captured email-bearing URLs, then delete or redact them according to the applicable retention policy.
- Add automated tests confirming that generated campaign links contain neither email addresses nor other recipient PII.
- Replace the plaintext