Security Policy

Security approach

SuperLabs treats security as part of architecture, software delivery, operations, and incident response. Controls are selected according to the system, data, users, contractual obligations, and risk.

Public website content must not be interpreted as a certification, audit opinion, warranty, or guarantee that a system is free from vulnerabilities. Client-specific controls and responsibilities are defined in the applicable engagement documents.

Report a suspected vulnerability

Send reports to cr@superlabs.co with the subject “Security vulnerability report”. Include the affected URL or asset, vulnerability type, clear reproduction steps, observed impact, date and time, relevant request or response details with secrets removed, and a safe way to contact you.

Do not include unnecessary personal data, credentials, live customer records, or copies of data obtained during testing. If sensitive transmission is required, first request an appropriate secure channel.

Responsible research expectations

• Test only public Super Commerce assets operated by SuperLabs and only to the minimum extent needed to confirm a suspected issue.
• Stop immediately if you encounter personal data, confidential information, credentials, payment data, or evidence of active compromise, and report the issue.
• Do not persist access, alter or delete data, create accounts for other people, install malware, exfiltrate information, or move laterally.
• Do not perform denial-of-service, load testing, spam, social engineering, phishing, physical intrusion, automated scanning at disruptive rates, or tests against third-party services.
• Give SuperLabs a reasonable opportunity to investigate and remediate before public disclosure. Coordinate disclosure timing and avoid sharing details that increase risk to users.
• Comply with applicable law. This policy does not authorize access that would otherwise be unlawful or violate third-party rights.

What happens after a report

SuperLabs will review reports for scope, reproducibility, severity, affected responsibility, and available remediation. We may request clarification, coordinate with a provider, or explain why an issue is out of scope or not accepted.

We aim to acknowledge useful reports and communicate material status when practical, but response and remediation time depend on severity, complexity, provider involvement, business risk, and available evidence. This policy does not promise a specific response time.

Out-of-scope findings

• Missing security headers without a demonstrated impact.
• Version disclosure, banner information, or best-practice observations without an exploitable condition.
• Clickjacking on pages with no sensitive action, self-XSS, or issues requiring unlikely user self-compromise.
• Rate-limit observations that do not demonstrate material security or availability impact.
• Reports generated only by automated scanners without validation and reproducible evidence.
• Attacks requiring compromised devices, accounts, credentials, or third-party infrastructure not caused by SuperLabs.
• Social-engineering, physical-security, employee, client, or third-party-provider testing.

Recognition and rewards

SuperLabs does not currently operate a public bug-bounty program and does not promise payment, reward, public recognition, or employment. Any recognition is discretionary and subject to legal, confidentiality, and security considerations.

A report does not create a contract or authorize the reporter to act on behalf of SuperLabs.

Client and project security

Security for client commerce systems is scoped against their architecture, data, users, payment responsibilities, markets, providers, regulations, and operating model. Public policy language does not override a signed agreement, security schedule, data-processing agreement, incident process, or service objective.

Clients should use the agreed support or incident channel rather than this public disclosure route for production incidents involving their environment.