Duelbits Security and Vulnerability Disclosure

Protecting accounts, platform data and the systems behind Duelbits is an important part of operating the Service. Security researchers who identify a potential vulnerability are encouraged to report it responsibly so the issue can be reviewed and, where necessary, corrected.

Duelbits.io is operated by Elevated Entertainment Ltd, company number 16101, with its registered office at Hamchako, Mutsamudu, Autonomous Island of Anjouan, Union of Comoros.

How Security Reports Are Assessed

Reported vulnerabilities are reviewed by the security team according to their technical impact, reproducibility and relevance to the Duelbits environment. Vulnerability severity is evaluated using the Bugcrowd Vulnerability Rating Taxonomy as a common reference point.

Reports are generally considered on a first-to-find basis. Recognition or a reward may be considered where a researcher is the first to report a previously unknown security issue and the finding leads to a meaningful code, configuration or security change.

There is no fixed minimum or maximum reward. Any reward is determined at the Company’s discretion and may vary according to the severity, practical impact and quality of the report.

Testing Takes Place on a Live Platform

Duelbits is a production environment used by real customers. Security research must therefore be carried out carefully and without disrupting the Service, accessing unrelated information or affecting other users.

When testing a possible vulnerability, researchers must follow these rules:

Only access accounts, information and resources that belong to you or that you are specifically authorised to test.
Do not alter, delete, damage, copy or expose another user’s data.
Use a vulnerability only as far as reasonably necessary to demonstrate that it exists.
Do not perform denial-of-service, traffic flooding or other availability testing.
Do not use aggressive automated scanning or scripts that may reduce platform performance.
Do not target Duelbits employees, customers or other individuals.
Stop testing if there is a reasonable risk of affecting the stability or security of the production environment.

Research That Is Not Permitted

Testing must not create unnecessary risk for the Service or its users. Activities involving service disruption, social engineering, unauthorised access or interference with third-party accounts are outside the permitted scope.

Researchers should demonstrate an issue with the minimum activity required to confirm it rather than attempting to determine how far it could be exploited.

Issues Normally Outside the Security Program

Certain findings do not normally qualify as actionable vulnerabilities unless they can be shown to create an additional and meaningful security impact.

Clickjacking on pages that do not perform sensitive actions.
CSRF affecting unauthenticated forms or functions without a sensitive consequence.
Findings that require physical access to a user’s device or a man-in-the-middle position.
Identification of an outdated or vulnerable software library without a working proof of impact.
CSV injection without a demonstrated security consequence.
General SSL or TLS configuration recommendations without an exploitable vulnerability.
Denial-of-service or any other test that could interrupt platform availability.
Text injection or content spoofing without the ability to demonstrate a meaningful attack vector.
Rate-limiting observations on endpoints unrelated to authentication where no practical security impact is shown.
General Content Security Policy recommendations without a demonstrated vulnerability.
Missing HttpOnly or Secure cookie attributes without a practical exploitation path.
General messaging-domain configuration issues such as missing or incomplete SPF, DKIM or DMARC records.
Findings limited to obsolete or unsupported browser versions.
Software version disclosure, server banners or descriptive error messages without further impact.
Tabnabbing without an additional demonstrated security consequence.
Open redirects where no additional security impact can be shown.
Session-related findings that depend on highly unlikely or unrealistic user actions.

What Makes a Useful Security Report

A report should contain enough information for the security team to reproduce the problem without needing to guess how the issue was discovered.

Please include:

A clear description of the vulnerability.
The affected page, endpoint or platform feature.
Step-by-step instructions for reproducing the issue.
The expected behaviour and the behaviour observed during testing.
Relevant URLs used while confirming the finding.
Evidence such as screenshots, video or a limited proof-of-concept where appropriate.
An explanation of the practical security impact.

Reports that contain verifiable evidence are easier to investigate and are generally required where recognition or a reward is being considered.

Keep Proof-of-Concept Testing Limited

A proof of concept should demonstrate that the vulnerability exists without causing unnecessary harm. Once enough evidence has been collected to reproduce the issue, further exploitation should stop.

Do not use a finding to obtain additional data, maintain access, move between systems or test unrelated accounts simply to demonstrate a greater possible impact.

User and Employee Accounts Are Out of Scope

Security testing must never be directed at customers, employees or other individuals. This includes attempts to obtain credentials, manipulate users, impersonate support staff or persuade someone to perform an action for testing purposes.

Testing should remain limited to the technical behaviour of systems and accounts that the researcher is authorised to use.

Service Availability

Findings must be investigated without intentionally placing additional load on Duelbits infrastructure. Stress testing, denial-of-service testing, traffic amplification and aggressive automated requests are not permitted.

If a potential vulnerability appears to involve platform capacity or availability, report the observation without attempting to reproduce a service outage.

Handling Sensitive Information

If sensitive information becomes visible unexpectedly during legitimate testing, do not download, modify, distribute or continue browsing through it.

Record only the minimum evidence required to explain the issue and include that information in the security report. Testing should stop where continuing could expose additional customer or platform data.

Duplicate and Previously Known Findings

A valid vulnerability may already have been reported by another researcher or identified internally. In these cases, the finding may be treated as a duplicate even where the submitted report is technically correct.

Reward eligibility generally applies to the first report that provides sufficient information for the issue to be confirmed.

Security Reward Decisions

A submitted report does not automatically qualify for payment. Reward decisions are made after the security team has confirmed the vulnerability, reviewed its impact and determined whether corrective action is required.

More significant vulnerabilities may receive greater consideration, while informational findings, duplicate reports and issues outside the defined scope may not qualify.

Responsible Disclosure

Researchers should allow the Duelbits security team reasonable time to investigate and address a reported vulnerability before publishing technical details about it.

Information that could place customers, accounts or platform infrastructure at risk should not be publicly disclosed while an unresolved security issue remains active.

Submitting a Vulnerability

If you believe you have identified a security issue, use the security or support reporting channel provided by Duelbits and include the reproduction details and supporting evidence described above.

Following these guidelines helps the security team investigate the report while limiting unnecessary risk to users and the live Duelbits environment.