One Step GPS’ Vulnerability Disclosure Policy

One Step GPS’ Vulnerability Disclosure Policy

Bug Bounty Program

Additional Links

Overview & Purpose
Last reviewed: January 2026This Vulnerability Disclosure and Bug Bounty Program outlines how security researchers can responsibly report security vulnerabilities affecting One Step GPS. We value coordinated disclosure conducted in good faith and aim to protect our users, customers, and systems while fostering a constructive security research community.
ScopeIn-ScopeAny design or implementation issue that materially affects the confidentiality, integrity, or availability of user data or core systems.
  • Cross-site scripting (XSS).
  • Cross-site request forgery (CSRF).
  • Authentication or authorization flaws.
  • Server-side code execution.
  • SQL injection.
  • Circumvention of access controls or permissions.
  • Security weaknesses in actively used third-party dependencies with demonstrable impact.
Out-of-ScopeThe following issues are explicitly out of scope and are not eligible for bounty awards:
  • Any report where the alleged exposure is the result of data intentionally published, embedded, shared, or made public by a customer or third party. This includes, but is not limited to, public repositories, client-side embedded keys, publicly shared URLs, or public resource configurations.
  • Social engineering, phishing, or physical attacks.
  • Issues requiring physical access to a device.
  • Vulnerabilities affecting outdated or unsupported browsers or platforms.
  • Missing best practices or informational findings without a clear security impact.
  • Automated scan results without demonstrated exploitability.
  • Denial-of-service testing, including traffic flooding, brute-force load testing, or resource exhaustion attacks, is strictly prohibited.
Clarifications & ExamplesPublic vs. Secret Credentials
Some keys or identifiers are designed to be publicly accessible (for example, publishable keys or client-side identifiers).
The presence of a public key alone does not constitute a vulnerability.
A report may be considered in scope only if it demonstrates that a One Step GPS vulnerability allows unauthorized access,
privilege escalation, data exposure, or system control beyond the intended design.
Examples of Out-of-Scope Reports
  • Public API or map keys intentionally embedded in client-side code.
  • Data exposed via customer-controlled public repositories or storage.
  • Resources intentionally configured as public by the customer.
Examples of Potentially In-Scope Reports
  • A publicly exposed identifier that, due to a One Step GPS authorization flaw, enables access to private customer data.
  • A publishable key that can be abused to perform unintended privileged actions due to a server-side validation issue.
  • Customer passwords found in a breach that, due to an authorization flaw, allows access to an account protected by MFA.
Authentication & MFA Considerations
  • If the account does not have MFA, and the exposure is due to user misconfiguration or password reuse, the report is generally out of scope.
  • If a password breach allows access only because of a One Step GPS misconfiguration or bypass of authentication protections, the report may be in scope.
  • If the account has MFA enabled, including MFA device rollover scenarios, and a vulnerability allows bypassing it, the report is in scope.
How to Report a Vulnerability
All in-scope vulnerabilities must be reported via email to bugbounty@onestepgps.com. Reports that do not follow the guidelines below may be delayed or considered invalid.
Email Subject Format
Use the following subject line format to help us quickly triage your submission:
Bug Report: [Short Descriptive Title] – [Estimated Severity]
Example: Bug Report: IDOR in Vehicle Export API – High
Required Report Contents
  • Title: A short, descriptive summary of the vulnerability.
  • Affected Environment: Production, staging, URL(s), endpoint(s), or component(s).
  • Description: A clear explanation of the issue and why it is a vulnerability.
  • Steps to Reproduce: Numbered, repeatable steps that allow us to reproduce the issue.
  • Proof of Concept (PoC): Requests, payloads, screenshots, or videos demonstrating impact.
  • Impact Assessment: What an attacker could realistically achieve and who is affected.
  • Severity Estimate: Your best estimate based on impact and exploitability.
  • Mitigation Suggestions (optional): Potential remediation ideas, if known.
Attachments & Supporting Evidence
  • All supporting materials should be embedded directly in the report email when possible.
  • Do not require access to external file-sharing services, cloud drives, or private repositories.
  • Ensure screenshots, logs, and recordings do not expose unrelated customer data.
Safe HarborWhen conducting security research in accordance with this policy, we consider such activity to be authorized and conducted in good faith.
  • We will not initiate or support legal action for good-faith research that complies with this policy.
  • We waive applicable restrictions in our Terms of Service for the limited purpose of security research.
  • We consider compliant research to be lawful under applicable anti-hacking and anti-circumvention laws.
Responsible Testing GuidelinesResearchers should not validate suspected sensitive data exposure by accessing additional real customer data.Reports should include minimal, redacted proof of concept sufficient to demonstrate impact without expanding exposure or accessing unrelated customer information.Denial-of-service testing, including traffic flooding, brute-force load testing, or resource exhaustion attacks, is strictly prohibited.
Disclosure & GuidelinesResearchers may only share vulnerability details with third parties after requesting and receiving explicit permission from the Program.
Adhere to this policy and other relevant agreements (e.g., Terms of Service). Report any discovered vulnerabilities promptly through official channels (bugbounty@onestepgps.com).
To encourage responsible research and avoid confusion with malicious activity, please adhere to the following guidelines:
  • Perform testing only on in-scope systems; respect out-of-scope systems and activities.
  • Avoid violating the privacy of others, disrupting systems, destroying data, or harming user experience.
  • Cease testing immediately if a vulnerability provides unintended access to sensitive user data (e.g., PII, PHI, credit card data, proprietary information) and submit a report.
  • Only interact with accounts you own, unless you have explicit permission from the account holder.
  • Do not attempt extortion or non-technical attacks such as social engineering, phishing, or physical attacks.
  • Do not view, alter, save, store, transfer, or otherwise access One Step GPS or user data without explicit authorization.
  • Be clear and succinct in your report; a short proof-of-concept link or example is invaluable.
  • Use only official channels to communicate vulnerability information with the Program.
  • The Program may modify its terms or terminate participation at any time.
Severity & Reward Structure
SeverityDescriptionExamples
CriticalSystemic compromise
Remote code execution.
SQL injection with full database compromise.
HighFull access to other users’ private data
IDOR with sensitive data exposure.
Stored XSS with account takeover.
MediumLimited access to private dataReflective XSS or CSRF with measurable impact.
LowLow-impact or configuration issuesClickjacking on non-sensitive pages; missing security headers; non-sensitive information disclosure.
EligibilityIssues resulting from customer-intentional publication or configuration of their own data are not eligible for bounty awards unless a One Step GPS vulnerability is demonstrated as the root cause. Awards are granted at our discretion. Submissions must be valid, in-scope, and reproducible to be eligible for a bounty.Award Considerations
  • Awards are based on confirmed impact and severity rather than difficulty to find.
  • First validated report of a unique issue is prioritized. Reports are considered duplicates if they share the same underlying root cause, even when discovered through different endpoints, parameters, or attack vectors.
  • Multiple related reports may be combined for reward calculation.
Criteria for Valid Reports
  • Clear reproduction steps.
  • Demonstrated security impact.
  • Affects an in-scope asset.
  • Not previously reported or publicly disclosed.
Invalid Reports
  • Customer-intentionally-exposed data.
  • Theoretical issues without exploitability.
  • Duplicate reports.
  • Automated scan output without manual validation.
Submission Standards
  • Automated or auto-generated reports will not be considered.
  • Reports that do not reference a One Step GPS asset or environment will not be considered.
  • Vulnerability descriptions that are overly generic or lack actionable details will not be considered.
  • Reports consisting solely of copied CVEs without context or verification will not be considered.
  • Speculative messages, such as those suggesting “Your site may be vulnerable to X,” will not be considered.
Expected Response Times
  • Initial acknowledgment within 5 business days.
  • Triage and validation typically within 10 business days.
  • Remediation timelines vary based on severity and complexity.
  • Response and remediation timelines are targets, not guarantees, and may vary based on investigation complexity, third-party dependencies, or business impact.
Legal & Disclosure TermsVulnerability details may not be disclosed publicly or to third parties without explicit written permission. Coordinated disclosure timelines will be determined on a case-by-case basis, typically after remediation or mitigation is complete.
The Fine Print
This program is discretionary and not a competition.
With the researcher’s permission, One Step GPS may publicly recognize individuals who responsibly disclose impactful vulnerabilities.
You are responsible for any applicable taxes or fees related to awards.
Reports from individuals we are prohibited by law from compensating are not eligible for awards.