By participating in this program, you agree to:

• Respect the Community Code of Conduct
• Respect the Intigriti Terms and Conditions
• Respect the scope of the program
• Not discuss or disclose vulnerability information without prior written consent (including PoC's on YouTube and Vimeo)

Validation times

We will validate all submissions within the below timelines, once your submission has been verified by Intigriti.

This remains at the discretion of Dashlane to award.

Introduction

We are happy to announce the Dashlane Bug Bounty Program.

Dashlane is looking for your help to identify impactful security vulnerabilities across its approved web application, website, API endpoints, browser extensions, autofill and autologin functionality, native mobile applications, business features, and SSO/SAML functionality.

Dashlane’s primary focus is protecting credentials, accounts, users, and organisations. Researchers should prioritise vulnerabilities that could affect credential confidentiality, account security, vault-related data, authentication flows, browser extension behaviour, API access controls, mobile application security, business/enterprise functionality, or shared credential workflows.

Only Dashlane-owned or Dashlane-operated assets are in scope. Researchers may report vulnerabilities affecting Dashlane-owned internet-facing assets, applications, APIs, browser extensions, mobile applications, business features, and credential security workflows, provided the report clearly explains why the affected asset is believed to be controlled by Dashlane.

Assets that are Dashlane-related but operated by third parties, vendors, partners, browser stores, app stores, payment processors, or other external providers are not automatically in scope unless Dashlane explicitly confirms otherwise.

Worst-case scenarios

We are especially interested in vulnerabilities that could lead to:

• A remote attacker forcing Dashlane to autofill, autologin, submit, expose, or send credentials to a rogue site
• Account takeover
• Authentication bypass
• Session or token compromise
• Unauthorized access to another user’s account, vault-related data, credentials, or sensitive account information
• Unauthorized access to business, team, organisation, or enterprise data
• Privilege escalation in business or enterprise functionality
• SAML or SSO bypass
• Abuse of group sharing, shared credentials, or emergency access workflows
• API authorization flaws affecting users, accounts, organisations, credentials, or sensitive data
• Mobile application vulnerabilities affecting credential security or account security
• Browser extension vulnerabilities affecting credential confidentiality or integrity
• Exposure of secrets, tokens, credentials, configuration, or sensitive user data
• Bypass of security controls protecting users, credentials, accounts, or organisations
• Cross-account or cross-organisation data access
• Remote code execution on Dashlane-owned applications or services
• Injection vulnerabilities with practical impact
• Sensitive data exposure through Dashlane-controlled APIs or applications
• Useful infrastructure information

The approved scope includes Dashlane-owned applications and services explicitly listed in the Assets section.

Key service areas include:

• Dashlane browser extensions
• Autofill and autologin functionality
• Dashlane web application
• Dashlane public website
• Dashlane API endpoints
• Dashlane iOS application
• Dashlane Android application
• Dashlane business and enterprise features
• SAML, SSO, group sharing, and emergency access functionality

Approved API endpoints include:

api.dashlane.com
ws1.dashlane.com
logs.dashlane.com

Approved web assets include:

www.dashlane.com
https://www.dashlane.com/app/
https://www.dashlane.com/business/try

Researchers should not actively test Dashlane hosts, domains, IPs, or services that are not explicitly listed in the Assets section.
Researchers must only test using accounts they own or accounts where they have explicit permission from the account holder.

Application

• Hosts, domains, IPs, or services not explicitly listed in the scope
• blog.dashlane.com
• Most issues related to rate limiting
• Reports about security headers without proven security impact
• Self-XSS in the web app or browser extension unless it can be used to impact another user
• Missing best practices without evidence of a security vulnerability
• Missing cookie flags on non-sensitive cookies without security impact
• User enumeration, including identifying whether an email address has a Dashlane account
• Disclosure of tools, libraries, frameworks, or versions used by Dashlane without security impact
• Access to “limited access” shared credentials, where the behaviour relates to the known limitation of the feature
• Referral program behaviour allowing free membership accumulation
• Subdomain takeover without proof of takeover
• SPF, DKIM, or DMARC remarks
• Dead links
• TLS configuration findings, including expired certificates or cipher suite observations, without practical exploitability
• Embedded API keys with limited scope, unless they can be abused to impact Dashlane services
• Command injection in Excel through CSV without practical security impact
• Leak of subcodes to tracking third parties without evidence of abuse
• Local bypass of security policies on B2B plans
• Content injection without security impact
• Bypass of the “Unlock your secure items for 5 minutes” feature
• Theoretical vulnerabilities that require unlikely user interaction or circumstances
• Vulnerabilities only affecting unsupported or end-of-life browsers or operating systems
• Broken link hijacking
• Tabnabbing
• Content spoofing and text injection without security impact
• Clickjacking on pages with no sensitive actions
• CSRF on forms with no sensitive actions
• Permissive CORS configurations without demonstrated security impact
• Software version disclosure, banner identification, descriptive errors, or stack traces without practical impact
• Open redirects without additional security impact

Mobile

• Lack of SSL pinning without demonstrated security impact
• Lack of jailbreak detection
• Attacks requiring a compromised device or prior control of the host system
• Keylogger-based attacks
• Memory dumping attacks requiring prior device compromise
• Issues only possible on a rooted or jailbroken device without practical impact against a normal user
• Missing hardening controls without evidence of a security vulnerability
• API key leakage used only for insensitive actions or limited-scope activity

General

• Any asset not explicitly listed in scope
• Public disclosure or disclosure to third parties before Dashlane has addressed the report
• Disclosure to vulnerability brokers before Dashlane has addressed the report
• PoC videos hosted on YouTube or other public services, including unlisted videos
• Reports containing multiple unrelated vulnerabilities instead of one report per vulnerability
• Duplicate reports
• Previously known issues
• Reports without clear reproduction steps
• Reports without practical security impact
• Reports that only state a best-practice concern without evidence of a vulnerability
• Social engineering
• Phishing
• CSP configuration opinions
• Opening support requests
• Spam
• Malware distribution
• Physical attacks against Dashlane offices, employees, contractors, users, or third parties
• Denial-of-service or distributed denial-of-service attacks
• Excessive traffic or high-volume automated testing
• Automated or scripted account creation
• Attacks that are noisy to users or administrators
• Attempts to access, leak, manipulate, destroy, or exfiltrate user data
• Testing against accounts you do not own or do not have explicit permission to test
• Any activity that could affect the availability, integrity, privacy, or safety of Dashlane systems, users, or data

This program follows Intigriti's triage standards based on the proof of concept.

Severity may be increased where a vulnerability affects:

• Credential confidentiality
• Autofill or autologin behaviour
• Browser extension security
• Account takeover
• Authentication or session security
• User vault-related data
• Shared credentials
• Business or enterprise data
• SAML or SSO functionality
• Group sharing or emergency access
• Cross-account or cross-organisation access
• Dashlane-controlled APIs
• Native mobile application security
• Exposure of secrets, tokens, credentials, or sensitive user data

Severity may be reduced where:

• The report lacks a clear proof of concept
• The issue is theoretical
• The issue requires unrealistic user interaction
• The issue affects only the reporting user’s own account
• The issue relies on a compromised device or prior control of the host system
• The issue is a best-practice-only finding
• The issue affects an out-of-scope asset
• The issue does not demonstrate practical security impact
• Reward eligibility

To qualify for a reward, researchers should:

• Be the first to report the specific vulnerability
• Provide a clear written description of the vulnerability
• Include clear steps to reproduce
• Include screenshots, request/response samples, logs, or proof-of-concept code where useful
• Disclose the vulnerability directly and exclusively through this program
• Avoid public disclosure or third-party disclosure before Dashlane has addressed the report
• Submit one report per vulnerability

Reports outside the scope of this program may be closed as not applicable.

Reports containing zero-day vulnerabilities will be reviewed and assessed on a case-by-case basis and may not follow the standard reward structure.

Where can we get credentials for the app?

You can self-register on the application but please don’t forget to use your @intigriti.me address.

Do you offer a Bug Bounty Program?

Yes, Dashlane also operates a private Bug Bounty Program. Strong, high-quality reports submitted through this VDP may be considered for an invitation to the Bug Bounty Program.

Is blog.dashlane.com in scope?

No. blog.dashlane.com is out of scope.

Are assets not listed in the scope allowed?

Yes, for this VDP, researchers may report vulnerabilities affecting Dashlane-owned or Dashlane-operated assets, even if the asset is not individually listed, provided the report clearly explains why the asset is believed to be controlled by Dashlane.

Third-party, vendor-operated, partner-operated, or externally controlled services are not automatically in scope.

Can I test Dashlane accounts belonging to other users?

No. Researchers must only test accounts they own or accounts where they have explicit permission from the account holder.

Can I create accounts using automation?

No. Automated or scripted account creation is not allowed.

Can I submit a user enumeration report?

No. Reports describing how to determine whether an email address has a Dashlane account are out of scope.

Are embedded API keys in scope?

Only where the API key can be abused to impact Dashlane services. Embedded API keys with limited scope and no demonstrated abuse are out of scope.

Are missing headers, TLS issues, or best-practice findings accepted?

Only where there is clear practical security impact. Best-practice-only findings are out of scope.

Can I report issues with limited access shared credentials?

The known behaviour around “limited access” shared credentials is out of scope unless a new and clearly exploitable security impact is demonstrated.

Can I upload PoC videos to YouTube as unlisted?

No. Researchers must not use YouTube or any public video hosting service, even unlisted, for proof-of-concept videos.