DailyPay VDP

Introduction

At DailyPay, we are dedicated to delivering secure products and services. We value the input of independent security researchers and the broader community in helping us maintain a secure technological landscape.

If you believe you've identified a potential security vulnerability within DailyPay's systems, we want to hear from you.

TIP: Exceptional reports don't just help us stay safe, they may also warrant an invite to our private, paid Bug Bounty program!

Response Targets

We make a best effort to meet the following response timelines for researchers:

Program Rules & Disclosure

To remain in good standing, we ask that you adhere to the following:

• Confidentiality: Do not discuss vulnerabilities (including resolved ones) outside this program without express written consent.
• Standard Guidelines: Follow the HackerOne Disclosure Guidelines.
• Report Quality: Submit one vulnerability per report (unless chaining for impact). Reports must include clear, reproducible steps.
• Duplicates: Only the first reproducible report of a vulnerability will be triaged.
• Good Faith Effort: Make a good faith effort to avoid privacy violations, data destruction, or service degradation. Only interact with accounts you own.
• Prohibited: Social engineering (phishing, vishing, etc.) against DailyPay employees or users is strictly forbidden.
• Auto-Generated Client SDKs: DailyPay publishes client SDKs generated by third-party tooling (Speakeasy). These codebases are not written or directly maintained by DailyPay. Findings in SDK repositories require the same production impact evidence as all GitHub repository reports Without demonstrated production impact, these will be marked as Informational and are not eligible for bounty.

SDK repos covered by this rule:

• dailypay-typescript-sdk
• dailypay-go-sdk
• dailypay-dotnet8-sdk
• dailypay-dotnet9-sdk

Scope & Identification

Testing is strictly limited to assets listed as "In-Scope." Anything not listed is considered Out-of-Scope. If you discover a vulnerability in an unlisted asset, please contact [email protected] before submitting.

Mandatory Testing Header

To ensure our SOC doesn't block your activity, all manual and automated testing tools must include the following HTTP header: X-HackerOne-DailyPay-Research: [Your H1 Username]

Open Source Repository Requirements

For vulnerabilities reported against our GitHub repositories (https://github.com/dailypay/*):

All submissions must demonstrate production impact:

• Provide evidence that the vulnerable code/version is deployed in DailyPay production systems
• Show actual exploitation or security impact within our live infrastructure
• Include proof that vulnerable code paths are active and reachable in production

Not accepted:

• Theoretical vulnerabilities in library code without production impact evidence
• Code-level findings without proof of deployment in our production environment
• Vulnerabilities in archived or unmaintained repositories

Before You Submit

Please confirm all of the following before submitting a report:

• My vulnerability affects production systems (not test, dev, or staging)
• I have a working proof of concept
• I can demonstrate actual security impact (not just theoretical)
• My attack scenario is realistic (not dependent on extensive social engineering)
• This is not just a missing security header or best practice violation
• The vulnerability is not in an out-of-scope asset listed below
• If reporting on a GitHub repository, I have evidence the vulnerable code is deployed and exploitable in production

Reports that do not meet these criteria will be marked as N/A or Informational without further review.

What Makes a Strong Report

To be considered a high-quality submission, your report should demonstrate all three of the following:

1. Working Proof of Concept Demonstrate the vulnerability against our production systems with step-by-step reproduction instructions, evidence (screenshots, HTTP requests/responses, or video), and a clear explanation of the security impact. Reports lacking an adequate PoC will be marked as N/A or Informative.

2. Clear Security Impact Your report should show at least one of the following:

• Unauthorized access to data or functionality
• Authentication or authorization bypass
• Remote code execution
• Data exfiltration or modification by unauthorized parties
• Financial loss through attacker-controlled actions

We do not accept: data validation issues without security consequences, business logic flaws that only affect operational reliability, compliance violations without a demonstrated exploitation path, or issues that only cause service degradation or incorrect processing.

3. Realistic Attack Scenario Exploits requiring extensive user interaction will be considered lower severity or informative. This includes scenarios requiring the victim to take multiple suspicious actions, install malicious software, or visit attacker-controlled sites in ways that a typical security-aware user would recognize as suspicious.

Note: Exceptional submissions demonstrating significant, well-documented impact are most likely to result in an invitation to our private Bug Bounty program.

Out-of-Scope Vulnerabilities

When reporting, please focus on exploitability and security impact. The following issues are generally considered out of scope:

Third-Party & Open Source Libraries

We do not accept reports for known CVEs in third-party libraries unless you demonstrate:

• The vulnerable version is running in our production environment
• Our implementation uses the vulnerable functionality
• You have a working exploit in our specific production context

This requirement also applies to DailyPay's own open-source libraries (including httpigeon and other repositories under github.com/dailypay/*). Code-level findings without demonstrated production impact will be marked as Informational.

Vulnerabilities in open-source projects we depend on will not be accepted without proof they are exploitable in our deployed implementation.

Non-Production & Test Assets

The following are explicitly out of scope:

• Test repositories, take-home assignments, and example code
• Development, staging, or QA environments (unless explicitly listed as in scope)
• Internal tools not accessible to end users
• GitHub repositories that do not power production services
• Archived repositories (no longer maintained)

Web & General Policy

• CSRF/Clickjacking: On pages with no sensitive actions or unauthenticated forms.
• Configuration: Missing best practices in SSL/TLS, CSP, or HTTP headers (e.g., HttpOnly, Secure flags) without a demonstrated exploit.
• Email: Missing SPF/DKIM/DMARC records or general email best practices.
• Redirects: Open redirects unless a significant security impact is demonstrated.
• Information Disclosure: Software version disclosure, banner identification, stack traces, or descriptive error messages.
• Rate Limiting: On non-authentication endpoints.
• CORS misconfiguration without an exploitation scenario.
• Broken link hijacking issues.
• Improper logout functionality and improper session timeout.
• Disclosure of IP addresses.
• User enumeration without a demonstrated account takeover path.
• Missing security headers (CSP, HSTS, X-Frame-Options, etc.) without a demonstrated exploit.

Technical Limitations

• User Interaction: Issues requiring unlikely or "perfect world" user interaction (e.g., Tabnabbing).
• Access: Attacks requiring MITM or physical access to a user's device.
• Environment: Debug info or partial source code disclosure in development/staging environments.
• Known Vulnerabilities: Vulnerabilities in outdated browsers (less than 2 stable versions behind), "Zero-day" vulnerabilities patched within the last 30 days, or previously known vulnerable libraries without a working Proof of Concept.
• Archived Repositories: Findings in archived repositories will not be accepted as these are no longer maintained.
• Theoretical Issues: Vulnerabilities that are not exploitable or cannot be demonstrated as exploitable against production systems.

Low Impact / Automated

• CSV Injection: Without a demonstrated vulnerability.
• Scanner Reports: Raw, unvalidated output from automated tools.
• Public Data: Publicly known Google API keys, leaked credentials from dark web sources, or breach lists.
• WordPress: Issues on unauthenticated endpoints of WordPress sites or XMLRPC.
• Operational/Business Logic Issues: Input validation failures, retry logic flaws, or processing errors that do not create an attacker-controlled security impact.

Mobile Specific

• Lack of SSL Pinning or Jailbreak detection.

Thank you for helping keep DailyPay and our users safe!