## 1. Allowed languages

- Russian;
- English.

---

## 2. Scope
The program includes only the following resources:
```
- myreviews.ru;
- myreviews.dev;
- subdomains *.myreviews.dev.
```
If an asset is not listed above, it is not part of the program. A domain appearing in source code, a CSP, DNS records, historical data, or a third-party integration does not bring it into scope.

The latest REST API documentation is available at `https://myreviews.ru/api-docs`.

The documentation can help you understand an endpoint's purpose, request format, and authentication requirements. However, whether an endpoint is present in or absent from the documentation does not, by itself, prove that a vulnerability exists. We require a demonstrated security impact.

## 3. What We Are Looking For

The program focuses on three areas.

### Payment Bypass

Please submit a report if you are able to:

- activate or renew a paid plan without making the required payment;
- obtain a paid feature, quota, or limit without paying for it;
- actually use a paid feature beyond the limits of your current plan.

Client-side changes, a payment link showing an unusual amount, a technical status, or an API record do not qualify as a payment bypass unless you actually receive the paid service or feature.

### Parser Limit Bypass

Please submit a report if you are able to:

- obtain parsing results beyond your plan or quota;
- successfully complete a parsing operation while bypassing account restrictions;
- use the free plan to obtain results from review platforms that are not included in that plan. The free plan currently supports Yandex only.

The creation of a task, a changed counter or status, or a `200 OK` response does not demonstrate a bypass unless the resulting data or functionality is actually available to the user.

### Обход ограничений автоответов

### Auto-Reply Limit Bypass

Please submit a report if you are able to:

- generate or send auto-replies beyond your plan or quota;
- send a reply on behalf of another account or organization without its authorization.

Changes to a draft, template, counter, status, or user interface do not qualify as a vulnerability unless an auto-reply is actually generated or sent.


## 4. Critical Findings

Although the program's main focus is described above, we will also consider a critical vulnerability if it allows an attacker to:

- take over another user's account or act on behalf of the account owner;
- obtain valid authentication credentials;
- access a significant volume of non-public, sensitive user data;
- execute code or gain control over MyReviews infrastructure;
- gain unauthorized access to data or permissions across multiple accounts.

These reports are reviewed on a case-by-case basis. A vulnerability class, CVE identifier, or high CVSS score does not, by itself, make a report critical. The report must demonstrate real-world impact.

## 5. How to Demonstrate a Vulnerability

We require a reproducible scenario and evidence of the actual result of exploitation.

The following do not qualify as sufficient evidence:

- an assumption that the issue could be developed into a more serious attack;
- data changed only in the user interface;
- an unusual API response with no user-accessible result;
- a misconfigured security control without a working exploit;
- a theoretical attack chain without a complete proof of concept.

Use your own test accounts and the minimum number of requests and objects necessary for testing.

### What We Consider Authentication Credentials

- a password or password equivalent;
- a password hash;
- a valid session token, access token, or refresh token;
- an API key;
- an account recovery token or code.

An email address, UUID, numeric ID, internal name, status, or other technical metadata is not considered an authentication credential unless it independently allows someone to sign in to an account, access non-public data, or act on behalf of a user.

## 6. What We Do Not Accept

If the demonstrated impact does not fall under Section 3 or Section 4, the report will be closed as Out of Scope. The vulnerability class or CVSS score does not change this.

In particular, we do not accept:

- software versions, headers, stack traces, internal hostnames, IP addresses, paths, or diagnostic messages;
- CORS, CSP, CSRF, SameSite, X-Frame-Options, Secure, HttpOnly, or similar configuration issues without a working exploit;
- open redirects, HTTP `OPTIONS`/`TRACE`, missing security headers, or other hardening observations;
- reports based solely on a software version or CVE;
- theoretical scenarios or issues in unreachable legacy code;
- missing CAPTCHA, SMS verification, or rate limiting;
- weak password policies or user enumeration;
- long token lifetimes without a way to obtain and use another user's token;
- logout CSRF or observations about stateless JWTs without access to another user's account;
- registering with an unverified email address and signing in to an account you created yourself;
- brute-force attacks or credential stuffing;
- spam or abuse of public forms;
- DoS/DDoS, connection exhaustion, or resource exhaustion;
- self-XSS or XSS that works only within your own account;
- attacks that require control over the victim's device, browser, or local network;
- DNS, DMARC, SPF, DKIM, or DNSSEC observations;
- IDN homograph attacks, Broken Link Hijacking, or Domain Hijacking without an impact described in Section 3 or Section 4;
- issues in third-party services that have no direct impact on MyReviews.

XSS, CSRF, SSRF, IDOR, injection, race conditions, and other well-known vulnerability classes are not automatically in scope. What matters is the demonstrated impact described in Section 3 or Section 4, not the vulnerability class itself.

## 7. MyReviews-Specific Information

This section explains how the product works and does not expand the program's scope.

### Public Organization and Widget Data

MyReviews provides public data for organization profiles and widgets embedded on customer websites. Accessing this data without authentication, with another user's JWT, or through a sequential ID is not, by itself, an IDOR vulnerability.

This applies in particular to the following APIs:

- `GET /v1/firm/view?id=<id>` с любым значением `demo`;
- `GET /v1/widget/get-firm/...`;
- `GET /v1/widget/get-reviews/...`;
- other endpoints that return data for a public organization profile or widget.

In this context, public or technical data includes:

- an organizations name, address, image, website, and description;
- UUIDs, numeric IDs, `parent_id`, and object types;
- ratings, review counts, public review text, links, avatars, and photographs;
- connected review platforms, dates, statuses, and aggregate counters;
- public widget, QR code, or profile configuration;
- setting flags, provided they do not disclose recipients, tokens, authentication credentials, or notification content;
- `isPaid`, `active`, and similar status values that do not allow a paid or restricted action to be performed.

A `false` response from `GET /v1/firm/access` means that the user does not have permission to perform account management actions. It does not make the organization's public profile confidential.

Do not enumerate identifiers at scale. A minimal proof of concept using your own test objects is sufficient.

### Reviews and Widgets

Review text, links, avatars, photographs, and metadata collected from public review platforms are not considered confidential.

The existence of a public review-submission endpoint or feedback form is not, by itself, a vulnerability.

Test review creation only on organizations that you own and use for testing. Do not post even a single test review, payload, or message such as `test XSS` or `test CSRF` to a real customer's profile without prior approval. Such reviews become public and are visible to users.

The number of widgets per organization is not limited. Creating multiple widgets is an intended feature of the service.

### Companies, Quotas, and Plans

Creating a company record beyond a displayed limit, using a demo or free plan, or producing a negative counter does not, by itself, demonstrate a payment bypass.

You must show that the additional company actually received a paid feature, completed a restricted operation, or obtained a resource without payment.

An inactive record, technical status, `service` record, or running process with no user-accessible result does not qualify as a payment bypass.

### Parsers

A server-side request to an allowed external review platform is an expected part of the parsing process.

Paid plans currently provide access to the same set of review platforms. The free plan supports Yandex only.

We accept parser-related reports only if they demonstrate a quota bypass or a critical impact described in Section 4.

An allowlist bypass that demonstrates only a blind callback to an external URL you control is out of scope.

### Auto-Replies

You must demonstrate that an auto-reply was actually generated or sent beyond the applicable plan limit, or that a reply was sent on behalf of another account without authorization.

Changes to a draft, template, counter, status, or user interface without generating or sending a reply are out of scope.

### SSRF

Blind SSRF, an external out-of-band callback, or the ability to reach an internal network is not sufficient on its own.

An SSRF report may be accepted as a critical finding only if it safely demonstrates access to sensitive internal data, a trusted endpoint, a metadata service, or another independently critical impact.

To test internal reachability safely, use only `192.168.4.72:8000`.

Do not scan internal address ranges, metadata endpoints, ports, or services without prior written approval.

## 8. Safe Testing

Use only:

- accounts you own;
- accounts belonging to users who have explicitly authorized testing;
- test accounts provided by MyReviews.

In most cases, two of your own test accounts and a small number of your own objects are sufficient for a proof of concept. If you need more, contact us before continuing.

Please stop testing as soon as you have confirmed the impact.

Without prior approval, you must not:

- access accounts, data, or resources belonging to other users;
- enumerate IDs, email addresses, usernames, companies, or other objects at scale;
- send requests, messages, emails, reviews, or files at scale;
- post test reviews, payloads, or references to vulnerabilities on profiles belonging to other organizations;
- perform load testing or any action that could cause a DoS/DDoS condition;
- use social engineering or phishing;
- attack employees, customers, or partners;
- upload malware, spyware, large files, or other dangerous files;
- modify, delete, or replace server-side files, except for files belonging to your own test accounts.

If you discover an arbitrary file-read issue, you may read only `/etc/ufw/user6.rules`.

Obtain prior written approval before performing any other file-related action.

## 9. Report Requirements

Please include:

- what happened and why it is a security issue;
- the impact described in Section 3 or Section 4 that you demonstrated;
- the affected asset and endpoint;
- minimal reproduction steps;
- requests and responses with secrets redacted;
- the IDs of the test accounts and objects you used;
- the date and time of testing;
- screenshots, videos, or other supporting evidence;
- remediation recommendations.

Do not include active tokens, passwords, keys, or personal data in clear text. Redact them in the report, screenshots, and videos.

If demonstrating the impact would require interacting with another user's data, MyReviews infrastructure, or service availability, contact the program team before proceeding.

## 10. Severity and Rewards

We first determine whether a report is in scope. We then assess its severity and reward amount.

We consider:

- the demonstrated impact;
- the affected data, features, and permissions;
- the prerequisites and complexity of exploitation;
- whether user interaction is required;
- the number of affected users and resources;
- the financial and infrastructure risk.

The maximum reward is RUB 50,000 before tax.

Zero-day and one-day vulnerabilities are reviewed individually if they meet the requirements of Section 3 or Section 4.

## 11. Duplicates

A reward is issued for the first report that contains enough information to reproduce and remediate a previously unknown vulnerability.

A report is considered a duplicate if, before receiving it, we already had another report, internal audit finding, or internal task containing sufficient information about the same root cause.

A different endpoint, a new exploitation technique, or a more detailed proof of concept is not considered a separate vulnerability if addressing it requires fixing the same root cause.

Duplicate reports are not eligible for rewards.

---

## 12. How to Request Additional Testing Time

1. Register your own test accounts.
2. Send the registration email address and a link to your verified Standoff 365 profile to `bugbounty@myreviews.ru`.
3. After reviewing the information, the program team may add extra paid-plan testing time to your account.

MyReviews

MyReviews is a popular Russian service for automating the collection, monitoring, and management of customer reviews. It helps businesses track their online reputation, gather feedback, and improve their search engine rankings.

Craftum is a website builder that provides ready-made templates and modules so that you can quickly create a website for any purpose, be it sales, personal branding, a portfolio, or your company's promotion.

Craftum

# Program rules

## Supported languages

- English
- Russian

### Contents

- Vulnerabilities to look for
- Vulnerabilities NOT to look for
- Participation rules
- Rewards
- Useful information
- How to register test accounts
----------

### SQL injection testing rules

When testing for SQL injection vulnerabilities, researchers must adhere to the following policy.

Only the following actions are allowed on the server:

- Get information about the current database (SELECT database()), its version (SELECT @@version), the current user (SELECT user() or SELECT system_user()), or hostname (SELECT @@hostname).
- Get the database schema (SELECT table_schema), list of tables (SELECT table_name), and table column names (SELECT column_name).
- Perform mathematical, conversion, or logical queries (including using SLEEP) without retrieving data (excluding those mentioned above).

Any other actions must be coordinated with the company.
### File read and upload rules

When testing for arbitrary file read vulnerabilities or arbitrary file upload vulnerabilities on the server, researchers must adhere to the following policy.

Actions prohibited during file upload testing include the following:

- Change, modify, delete, or replace any files on the server (including system files) except for files associated with the researcher's own account or the account of a user who gave explicit consent for such actions.
- Upload files that could cause a denial of service (for instance, large files).
- Upload malicious files (such as malware or spyware).

If an arbitrary file read vulnerability is discovered on the server, the researcher is only allowed to read the /etc/ufw/user6.rules file. Any other actions must be coordinated with the company.
### Vulnerabilities to look for

We are primarily interested in critical server-side vulnerabilities. Still, you're welcome to hunt for any other types of vulnerabilities. If you are unsure whether to contact us about an issue you have found, check if it's on the "Vulnerabilities NOT to look for" list. If it's not on the list, feel free to submit a detailed report.

Examples of vulnerabilities we'll be happy to reward you for are listed below (the list is incomplete and is based on the OWASP Top 10).
#### General

- Remote code execution (RCE)
- Injections (such as SQL and XML injections)
- LFR/LFI/RFI
- Blind SSRF
- Business logic vulnerabilities
- IDOR
- Access control vulnerabilities
- Sensitive information disclosure
- Account hijacking
- XSS and CSRF that affect sensitive data
- Bypass of financial tools (fund withdrawal), removal of restrictions on chargeable operations and services
### Vulnerabilities NOT to look for

Out-of-scope submissions include the following:

- Client-generated XSS vulnerabilities within our website builder platform are out of scope (For example: if a user added <script>alert(1)</script> to their HTML block - this is not a constructor bug)
- XSS that can only be performed from a single account (regardless of the number of account users)
- Disclosure of non-confidential information, such as product versions
- Disclosure of public user information, such as usernames
- Simplified registration and authorization without CAPTCHA validation, SMS verification, or other best practices
- Reports from security scanners and other automated systems
- Vulnerability reports based solely on software or protocol versions with no credible proof of concept
- Lack of security mechanisms or non-compliance with recommendations (for example, the absence of a CSRF token) without mentioning specific negative consequences
- Logout CSRF
- Blind SSRF with no ability to scan or send requests to the internal infrastructure
- Framing
- IDN homograph attacks
- Disclosure of public information about a user or a community
- Attacks that rely on full access to a user device or page, or browser profile
- Vulnerabilities in partner services and products that do not directly affect the security of Craftum products and services
- Session fixation
- Self-XSS
- Scripting in PDF documents
- Hypothetical attacks without proof of feasibility
- Any issues related to bruteforcing
- Problems associated with validation of input data in any form without an actual vulnerability 
- Any possibilities of user enumeration, login enumeration, and so on
- Clickjacking
- Broken Link Hijacking, Domain Hijacking;
- Changes in tariff plans
- Problems with DMARC/SPF, DNSSEC, DKIM records;
- Any types of hijacking
- Missing security headers
- Missing security flag or HttpOnly cookie
- Unvalidated redirects and forwards
- Open redirects, unless they compromise the security of the service (for example, by allowing authorization token theft)
- Web application firewall (WAF) bypass, or direct access to the server
- HTTP OPTIONS or TRACE methods enabled
- Man-in-the-middle (MITM) attacks or interception
- Attacks that require a user to be present online 
- Any product features implemented without taking into account best cybersecurity practices, dark patterns, and so on
- DoS/DDoS
- Possibility of sending a large number of messages
- Possibility of sending spam or malware files (for example, spam registration or password recovery emails)
- Disclosure of non-sensitive API methods and public API tokens that do not provide access to data, operations, or privileges
- Exposure of EXIF image metadata
- Vulnerabilities that allow disclosure of an IP address without revealing other identifying information about the client (such as the client's full name or login)
- The “Got an Idea” section
----------
### Participation rules

By participating in our bug bounty program, you confirm that you have read and accepted these participation rules. Violation of any of these rules may result in forfeiture of rewards.
#### General rules

- The scope of the bug bounty program is limited to technical vulnerabilities in the company's services. If you encounter problems that have nothing to do with security, please contact customer support.
- If you discover a 0-day or 1-day vulnerability for which an official patch was released less than a week ago, your report will be considered on an individual basis and may be awarded with a bounty at the discretion of the Craftum security team.

#### Testing rules

- For testing, you can use only your own accounts, accounts of users who have explicitly given their consent, or accounts provided for testing with bonus rates. Do not attempt to access other people's accounts or any sensitive information.
- While searching for vulnerabilities, avoid compromising the confidentiality, integrity, and availability of information in our services.
- Any activity that could harm the company's applications, infrastructure, customers, or partners is strictly prohibited. Examples of prohibited activities include social engineering, phishing, denial-of-service attacks, and physical attacks on the infrastructure.
- To confirm a vulnerability, use the smallest possible proof of concept (POC). If this could impact other users or the system's performance, please contact us to get permission. Further exploitation of vulnerabilities is strictly prohibited.

-----

#### Report requirements

A report must contain the following:

* A full description of the discovered vulnerability
* A description of the impact on user and/or system security
* The steps required to reproduce the vulnerability, including the following (if possible):
       ◦ Screenshots
       ◦ Videos
       ◦ Requests/responses
       ◦ Code of the exploit used
       ◦ Date and time of request execution
* IDs of accounts used in testing
* Other materials required to reproduce the vulnerability
* Brief recommendations for remediation

-----

#### Vulnerability severity assessment
We reserve the right to make the final decision on the severity of the discovered vulnerability. After receiving the report, we conduct an internal investigation and determine the severity level based on multiple factors, including the following:
- Privileges required to conduct the attack
- Difficulty of discovery and exploitation
- Need for user interaction
- Impact on the integrity, availability, and confidentiality of the affected data
- Potential business and reputational risks
- Number of affected users

### Rewards
---
We reward external security researchers only for the discovery of previously unknown vulnerabilities, provided that all participation rules are complied with.
All reports are considered on a case-by-case basis with regard to the severity of the discovered vulnerability and the criticality of the affected system. 

---

##### Reward amounts

| Vulnerabilities                                                                   | Reward            |
| ---------------------------------------------------------------------------- | ------------------------- |
| Remote code execution (RCE)                                              | Up to ₽150,000              |
| SQL injection with access to critical data                        | Up to ₽100,000              |
| SQL injection                                                                | Up to ₽25,000               |
| Blind SSRF                                                                  | Up to ₽25,000               |
| Server-side vulnerability with disclosure of sensitive information (IDOR) | ₽10,000–₽75,000       |
| Stored XSS                                                                 | ₽10,000–₽20,000       |
| XSS, except for Self-XSS                                                           | ₽5,000–₽10,000         |
| Business logic errors                                                       | On a case-by-case basis |
| Other confirmed vulnerabilities                                             | On a case-by-case basis |

#### Additional information on rewards
We understand that each vulnerability is unique and may have an unexpected impact on security and business operations. The reward amounts listed in the table are based on our general guidelines, but if you identify a particularly severe vulnerability, the reward amount may be significantly increased.

Discovered vulnerabilities that pose a significant risk to our company and are eligible for a larger reward include the following:

- **Remote code execution (RCE)** that can take down our servers, destroy data, or disrupt business operations
- **SQL-injections** that can be used to access, manipulate, or completely delete critical data
- Any other scenarios that pose major risks to data, infrastructure, or users

In such cases, we are willing to consider increasing the reward up to ₽500,000 after assessing the risks and implications for the business.

We appreciate your efforts and are willing to reward you fairly for finding vulnerabilities, which helps us protect our users and our business.

#### How long does it take to check your report?

Vulnerability reports are reviewed by our internal security team. Response times may vary depending on our workload, but we try our best to process requests within two to three days.

#### Rules for handling duplicates

We reward only the first submissions (provided the report contains all the necessary information to reproduce the vulnerability). Any subsequent reports addressing the same vulnerability will be marked as duplicates. Reports containing similar attack vectors may also be considered duplicates if our security team believes that the information from an earlier report is sufficient to address all reported attack vectors or errors. Your report may be considered a duplicate of a report authored by another researcher or our security team.

#### Vulnerability disclosure policy

You may not share any details of the vulnerabilities you discover without written permission of the Craftum security team.

----------

### How to register test accounts

1. Sign up for the products to test using your own mailboxes.
2. After signing up, tell us your test account id. 
3. Provide a link to your Standoff 365 profile (**your profile must be verified**).
4. Send us an email with these details to bugbounty@craftum.com, and we will credit you with a bonus payment for testing.
##### Link to the service

- (Website builder) https://craftum.com/registration

**Issues found within the testing scope are evaluated based on their severity, to the maximum extent applicable. 
However, some cases may be considered on an individual basis if the discovered vulnerability has a significant impact on the whole infrastructure.**

Craftum is a website builder that provides ready-made templates and modules so that you can quickly create a website for any purpose, be it sales, personal branding, a portfolio, or your company's promotion.

https://craftum.com/

Programs