Thank you for helping to keep OpenCommerce Group’s businesses and our customers safe!
OCG SRC(OpenCommerce Group Security Response Center) is the point of contact of OpenCommerce Group security. We hope to strengthen cooperation and exchange security information with colleagues of the security industry, with the aim to protect OpenCommerce Group’s customers and the e-commerce industry ecosystem.
OCG SRC helps address the security needs across multiple product lines and for OpenCommerce Group’s business units namely ShopBase, PrintBase, PlusBase. As the security threat landscape evolves, effective security requires continual engagement and innovation. OpenCommerce Group’s security professionals are committed to continual improvement and strategic collaboration with other security partners to meet these challenges head-on.
Vulnerability disclosure and reward program
As part of this commitment, we are excited to work with other experts in the security community. We acknowledge the invaluable role that security researchers play in protecting our customers and the broader online ecosystem. There are 3 core business units in OpenCommerce Group, namely:
At OpenCommerce Group, Merchant trust and safety is our #1 priority. As such, we strive to provide the most secure platform possible. We will evaluate reported security issues based on the security impact to our users and the OpenCommerce Group ecosystem.
Please follow the OpenCommerce Group Disclosure Guidelines.
- Do not share the reports to any blog, social media…if not approved by OpenCommerce Group.
- Do not perform testing or hacking to active and real shops on ShopBase, including but not limited to user, shop, order information… If needed to verify the exploitability, please create your own shops
- Make every effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction of data during security testing.
- While researching and testing, we’d like to ask you to refrain from:
- Distributed Denial of Service
- Spamming, spoofing, phishing
- Email flooding
- Performing further attacks once you have proof of Remote Control Execution (RCE) attacks, this includes but not limited to Privilege Escalation, Internal Network scan, etc. Proceed to do so may have your bounties forfeited.
- Bulk downloading/extracting/crawling of exposed data beyond the need for proof-of-concept
- Qualifying vulnerabilities: Any design or implementation issue that substantially affects the confidentiality or integrity of user data is likely to be in scope for the program. Common examples include:
- Remote Code Execution
- Injections (SQLi, NoSQLi,…)
- Business Logic
- Cross-Site Scripting (XSS)
- Authentication-related issues
- Authorization-related issues
- Data Exposure
- Ineligible vulnerability types: We will refuse to process and reward any vulnerability that we have reason to determine does not have a significant impact on our customers and products, some examples are below (The list below is not limited, it includes things not listed)
- XSS - iFrames - Any issue related to the storefront area being displayed in a
<iframe>element in the admin area, for example in the Theme Editor.
- CSRF access to modify cart
- CSRF for Login or Logout - Any login / logout CSRF will be ineligible unless it is chained together with another vulnerability to demonstrate impact
- Insecure cookie handling for account identifying cookies
- Password reset tokens don’t expire when changing email address
- Email address change doesn’t require verification
- Issues with the SPF, DKIM or DMARC records on our domains
- Reflected XSS that requires full control of an HTTP header, such as Referer, Host, etc
- CSV / formula injection
- User or store name enumeration
- Insecure “Opening Soon” password
- Http missing security headers
- Banner grabbing issues (figuring out what web server we use, etc.)
- Findings from physical testing such as office access (e.g. open doors, tailgating).
- Broken authorization in admin dashboard that relating the staff role
- Nginx misconfiguration
If you follow these guidelines when reporting an issue to us, we commit to:
- Not pursue or support any legal action related to your research
- Work with you to understand and resolve the issue as quickly as possible.
If you believe you’ve found a security vulnerability in one of our products or platforms, please contact the OpenCommerce Group Security Response Center (OCG SRC) directly via
Please provide detailed reports with reproducible steps.
- Reception content:
- Vulnerability summary
- Affected URLs
- Vulnerability type
- Describe in detail how to reproduce the vulnerability
- How to fix
- Attached photo evidence.
Assets in Scope
The below list is unlimited, if you believe an asset is owned by OpenCommerce Group, please contact us via
email@example.com to verify.
Bounty amounts will be determined using Common Vulnerability Scoring System Calculator.
We reserve the right to make a final decision regarding the severity and rewards of a reported finding. If you are the first to report an issue, and we make a code or configuration change based on the issue, we will award you depending on how dangerous the vulnerability is and how it affects the system.
If you are the first researcher to report a confirmed security vulnerability, we will list your details in Hall of Fame (if desired). You must comply with our Security Policy to be considered for our Hall of Fame. We would like to thank the following security researchers for helping us secure our platform.