# Fourthwall — Vulnerability Disclosure Program

> Fourthwall operates a vulnerability disclosure program. Security researchers can report vulnerabilities through the process described below.

## Scope

### In Scope
- www.fourthwall.com
- *.fourthwall.com
- *-shop.fourthwall.com
- Fourthwall associated services and APIs

### Out of Scope
- Enumeration of random identifiers without proof of concept
- Tab nabbing
- Vulnerability scanner false positives / automated tool output without PoC
- Social engineering (phishing, employee impersonation, contacting Support under false pretenses)
- Broken links / unclaimed social media accounts (unless chained with impactful exploit)
- Content spoofing
- Bypassing HTML sanitization to make external HTTP requests at storefront level by privileged user
- DDoS — DoS in scope only if single user with single request disrupts the entire service, not one shop
- Issues exploitable only in outdated browsers or plugins
- SPF/DKIM/DMARC/CAA/TLSA/DNSSEC record issues (email spoofing)
- CSV / formula injection
- Hyperlink injection at storefront level by privileged user
- Insecure cookie handling for account-identifying cookies
- Perceived permission issues without data integrity/confidentiality impact
- Theoretical subdomain takeovers without supporting evidence
- Generic host header attacks without remote-victim evidence
- CVV validation during payment
- Disclosure of server or software version numbers
- Spam/flooding (email, SMS)
- Permitted password strength
- Missing HttpOnly/Secure flags and browser cache issues
- General configuration or policy suggestions
- Slow requests that eventually complete
- Usability or UI issues
- Third-party / partner security flaws (escalated to partner, not bountied)
- XSS exclusions: via Set-Header/full header control; via Inspect Element/console; Self-XSS requiring more than two steps; storefront or checkout XSS by store owner/staff (incl. *-shop.fourthwall.com); iFrame XSS in admin Theme Editor; legacy Rich Text Editor XSS by privileged user
- Creator HTML in store descriptions, product details and content fields (by design, not a vulnerability)
- CSRF for login/logout (unless chained) and cart modification
- CDN (static.fourthwall.com, cdn.fourthwall.com): arbitrary file upload by staff; sensitive-data disclosure (files intentionally public); stored XSS unless chained to a real scenario
- Fourthwall-hosted store false positives: staff access to admin endpoints; password-reset tokens not expiring on email change; insecure 'Coming Soon' password; staff with edit perms removing perms they lack; intended public files; lack of domain verification when adding custom domain; email not requiring verification on signup; user/store name enumeration
- Mobile apps: emulator-only issues; rooted/jailbroken/physical/debug access; biometric bypass; absence of app encryption; lack of binary protection or SSL pinning
- Race conditions not exploitable for access to sensitive information
- SSRF with only simple HTTP/DNS interactions
- Open redirects without user interaction (unless chained to demonstrate significant impact)
- HTML injection in emails by store owner/staff (unless chained with an eligible vulnerability)
- Perceived security weaknesses without remote-victim evidence (plaintext credentials in POST body, missing rate limits, brute force without demonstrated impact)

## Bounty Matrix

| Severity | Range |
|----------|-------|
| Informational | $0.00 – $0.00 |
| Low | $50.00 – $100.00 |
| Medium | $75.00 – $500.00 |
| High | $250.00 – $1,000.00 |
| Critical | $500.00 – $1,250.00 |
| Super Critical | $750.00 – $1,500.00 |

## Response Times

- Acknowledgment: within 168 hours

## Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorized conduct. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

## How to Report

Submit a vulnerability report at: https://vdp.fourthwall.com/report

> Important: Reports must be submitted personally by the researcher through the web form linked above. Do not submit reports programmatically — automated submissions are rate-limited and may be flagged as spam.

### Required Fields

- Title — short, specific summary naming the vulnerability class and where it occurs (e.g. "Stored XSS in profile bio field").
- Vulnerability type — one of: Cross-Site Scripting (XSS), SQL Injection, Cross-Site Request Forgery (CSRF), Insecure Direct Object Reference (IDOR), Server-Side Request Forgery (SSRF), Remote Code Execution (RCE), Authentication Bypass, Privilege Escalation, Information Disclosure, Broken Access Control, Security Misconfiguration, Cryptographic Failure, Other.
- Affected endpoint — the exact URL, endpoint, or component where the issue occurs.
- Description — what the vulnerability is, its security impact, and the root cause. Markdown is supported.
- Policy acceptance — the program policy must be accepted when submitting.

### Optional Fields

- Reproduction steps — numbered steps to reproduce from a clean state. Markdown is supported.
- Self-assessed severity — one of: Informational, Low, Medium, High, Critical. The security team performs its own assessment.
- Contact email — without it, status updates and bounty payments cannot be sent.
- Attachments — screenshots, logs, or proof-of-concept files. Accepted types: application/pdf, image/png, image/jpeg, image/gif, image/webp, text/plain, application/zip. Maximum 25 MB per file.

### Report Quality

- One vulnerability per report — submit separate reports for distinct issues.
- Include concrete evidence: exact requests and responses, payloads, and affected parameters.
- Describe the demonstrated real-world impact, not just the theoretical vulnerability class.

### What Happens Next

1. Acknowledgment — the security team confirms receipt.
2. Triage — the report is validated; clarification may be requested by email.
3. Assessment — the team assigns severity and, where applicable, a bounty.
4. Resolution — the fix is implemented and verified; disclosure follows the policy above.