EN

MyReviews

Company: Craftum
MyReviews — это популярный российский сервис для автоматизации сбора, мониторинга и управления отзывами клиентов. Он помогает бизнесу отслеживать репутацию в интернете, собирать обратную связь и улучшать позиции компании в поисковиках.
Rewards are paid to individual entrepreneurs and self-employed persons
Program description

Accepted languages

  • Russian;
  • English.

Scope

Only the following assets are in scope:
  • myreviews.ru;
  • myreviews.dev;
  • subdomains of *.myreviews.dev.
An asset is in scope only if it is explicitly listed above. A domain found in source code, CSP, DNS records, historical data, a third-party integration, or product links is not thereby added to scope.
We are primarily interested in server-side vulnerabilities with demonstrated, practical impact on the confidentiality, integrity, availability, or billing of MyReviews.

Official API documentation

The current REST API documentation is available at:
 https://myreviews.ru/api-docs
Use it to determine an endpoint's purpose, request format, required authorization, and whether the method is public. A public-method label, an endpoint's presence in client-side JavaScript, or API access without a JWT does not by itself demonstrate a vulnerability. Conversely, an endpoint's absence from the documentation does not demonstrate that it is confidential. In both cases, demonstrated security impact is required.

2. What we accept

A report may be accepted if it demonstrates independent, practical impact, for example:
  • remote code execution;
  • SQL, NoSQL, OS, XML, or other injection;
  • arbitrary file read or write with demonstrated impact;
  • SSRF with safely demonstrated access to an internal resource, a sensitive response, or another practical effect;
  • access to non-public data of another user or organization;
  • unauthorized modification of another user's data, settings, or permissions;
  • account takeover or persistent account access;
  • payment bypass, access to paid functionality, or another demonstrated financial impact;
  • XSS, CSRF, or clickjacking that allows data access, execution of a sensitive action, or authorization bypass;
  • a race condition that violates a significant authorization, billing, quota, data-access, or integrity invariant.
The vulnerability class name, the presence of a CVE, a sequential object identifier, an open endpoint, or a 200 OK response alone do not demonstrate a vulnerability. The report must show the actual result of exploitation.

3. What we do not accept

3.1. Observations without independent impact

The following are not accepted:
  • disclosure of software versions, technical headers, stack traces, internal hostnames, IP addresses, paths, service names, or diagnostic messages without independent impact;
  • absent or incomplete CORS, CSP, CSRF, SameSite, X-Frame-Options, Secure, HttpOnly, or similar protections without demonstrated exploitation;
  • open redirects, HTTP OPTIONS/TRACE, missing security headers, and similar hardening observations without impact;
  • reports based solely on a software version or CVE without a reproducible PoC in the product;
  • theoretical attack chains without a demonstrated practical exploitation path;
  • issues in unused legacy code, references, or integrations without actual reachability and impact.

3.2. Authentication, sessions, and registration

The following are not accepted without independent impact:
  • missing CAPTCHA, SMS verification, rate limiting, or another best practice in registration, login, or password recovery;
  • weak password policy;
  • user enumeration through an email address, username, telephone number, or another identifier;
  • session fixation without demonstrated account takeover;
  • a long token TTL where no method is shown to obtain another user's token or use it for independent access;
  • logout CSRF;
  • observations about stateless JWTs without demonstrated access to another account or its data.
We may separately consider a scenario in which a previously issued session token or recovery token provides or restores account access after a successful password change or recovery. Such a report must demonstrate the credential lifecycle on the researcher's own test account; a long TTL alone is insufficient.
Registration with an unverified email address, logging into a self-created account, inability to re-register an already used email address, and assignment of a role after an explicit action by an organization owner do not by themselves constitute an authorization bypass. To be considered, a report must demonstrate independent, confirmed access to another organization that is not simply the result of its owner selecting the attacker's account or email address and assigning it a role.

3.3. Public forms, abuse, and availability

The following are not accepted:
  • spam or bulk sending of messages, emails, or files;
  • brute force and credential stuffing;
  • abuse of public forms unless access to another user's data, accounts, payments, or another independent impact is demonstrated;
  • DoS/DDoS and scenarios based only on holding connections open, bulk requests, or resource exhaustion;
  • race conditions without a violation of authorization, billing, quota, data access, or another significant invariant;
  • self-XSS and XSS executable only within a single account;
  • attacks that require complete control of the victim's device, browser, browser profile, local network, or physical presence.

3.4. Third-party services and infrastructure

The following are not accepted:
  • vulnerabilities in partner services or products that do not directly affect the security of MyReviews;
  • file upload to a third-party service without an ability to host, execute, or use the files in the MyReviews context;
  • access to an external service or its API without demonstrated impact on MyReviews;
  • DNS, DMARC, SPF, DKIM, and DNSSEC observations;
  • IDN homograph, Broken Link Hijacking, and Domain Hijacking without demonstrated practical impact.

3.5. SSRF

Blind SSRF, external OOB correlation, and internal network reachability alone are not accepted.
To be considered, SSRF must safely demonstrate independent impact, such as access to an agreed internal test host, a sensitive response, a metadata service, a trusted internal endpoint, or another real effect.
Only the following internal test endpoint may be used to safely test internal reachability:
 192.168.4.72:8000
Do not scan internal ranges, metadata endpoints, ports, or services without prior written approval.

4. MyReviews-specific rules

4.1. Public organization and widget data

MyReviews provides public data for organization profiles and widgets embedded on customer websites. Its availability without authorization, with another user's JWT, or through a sequential numeric identifier does not by itself constitute IDOR or an access-control issue.
Do not submit reports based only on retrieving data through:
  • GET /v1/firm/view?id=<id> with any value of the demo parameter, including demo=0 and demo=1;
  • public widget APIs, including GET /v1/widget/get-firm/... and GET /v1/widget/get-reviews/...;
  • other APIs that return data for a public organization profile or widget.
Public data and technical metadata in this context include, without limitation:
  • an organization's name, address, image, website link, and public description;
  • UUID, numeric ID, parent_id, object type, and other technical identifiers;
  • ratings, counts and text of public reviews, links, avatars, photos, and associated public metadata;
  • connected platforms or services, dates, statuses, and aggregate counters;
  • public widget, QR-code, or profile configuration;
  • configuration flags, including boolean notification flags, when the response does not disclose recipients, tokens, credentials, or notification contents;
  • the existence of a plan, isPaid, active, and other metadata that does not permit operations or access to non-public data.
A false response from GET /v1/firm/access does not mean that all data returned by firm/view is confidential. This endpoint determines permissions for dashboard operations, not whether an organization profile is public.
A report concerning these endpoints may be accepted only if it demonstrates at least one of the following outcomes:
  • disclosure of non-public data, including email or Telegram recipients, tokens, passwords, API keys, payment, personal, or other sensitive data;
  • access to non-public content that is not publicly displayed;
  • actions performed on another organization's settings, data, permissions, or other resources.
Do not perform bulk ID enumeration. A minimal PoC using your own test objects is sufficient.

4.2. Reviews and widgets

Texts, links, avatars, photographs, and metadata of reviews collected by MyReviews from public platforms are not confidential by themselves.
The public availability of a review-creation endpoint or feedback form is not a vulnerability by itself. A report may be accepted if the public flow allows a privileged action, such as pinning a review, modifying another user's object, bypassing moderation, or another demonstrated impact.

4.3. Quotas, plans, and organizations

Creating organization records above a displayed limit, using a demo/free plan, or a negative counter value do not by themselves constitute a payment bypass.
A report may be accepted only if it demonstrates that an over-limit organization:
  • receives paid functionality that is actually available to the user;
  • performs a paid or restricted operation with an available result;
  • causes demonstrated financial loss or provides a resource without payment.
Inactive records, technical statuses, creation of a service record, a counter modification, or an isolated technical process execution without a result available to the user do not by themselves demonstrate a payment bypass.
Creating multiple widgets for the same organization is not a vulnerability without independent impact.

4.4. Parsers and external platforms

Characteristics of MyReviews parsers are not vulnerabilities without impact beyond normal collection of public data.
A server-side request to an allowed external platform is part of the parser's normal function. An allowlist bypass that demonstrates only a blind callback to an externally controlled URL is treated as a hardening observation until independent impact is demonstrated in accordance with the SSRF section.

5. Safe testing

5.1. General restrictions

Use only:
  • your own accounts;
  • accounts of users who gave explicit consent;
  • test accounts provided by the company.
Do not access another person's accounts, data, or resources without authorization. Use the minimum necessary PoC and stop testing immediately after confirming the vulnerability.
By default, a minimal PoC must use no more than two of your own test accounts and the minimum number of your own objects necessary to confirm the scenario. Bulk enumeration, scanning ID ranges, creating a large number of objects, or testing third-party data requires prior approval.
The following are prohibited:
  • social engineering, phishing, and attacks against employees, customers, or partners;
  • actions that may compromise the confidentiality, integrity, or availability of data and services;
  • bulk enumeration of IDs, email addresses, usernames, organizations, or other objects;
  • bulk sending of requests, messages, emails, reviews, or files;
  • testing that may cause DoS/DDoS;
  • testing third-party data or resources without prior approval;
  • uploading malware, spyware, large files, or other dangerous files.

5.2. File policy

When testing potential file read or upload issues, do not:
  • change, delete, replace, or modify any server files other than files belonging to your own test accounts;
  • upload files that may cause denial of service;
  • upload malicious files.
Where arbitrary file read is possible, you may read only:
 /etc/ufw/user6.rules
Any other file actions require the company's prior written approval.

6. Report requirements

A report must include:
  • a concise and accurate problem description;
  • a description of the demonstrated security impact;
  • the affected asset and endpoint;
  • minimal reproduction steps;
  • requests and responses with secrets redacted;
  • identifiers of the test accounts and objects used;
  • date and time of testing;
  • screenshots, video, or other necessary evidence;
  • remediation recommendations.
Do not submit working tokens, passwords, keys, other users' personal data, or other secrets in plain text. Redact them in text, screenshots, and video.
If impact requires actions that may affect third-party data, infrastructure, or service availability, request approval from the program team first.

7. Severity and rewards

The MyReviews team determines the final severity and reward amount after internal review.
The assessment considers:
  • demonstrated impact on confidentiality, integrity, and availability;
  • the affected data, operations, and privileges;
  • access requirements, exploitation complexity, and user interaction;
  • the scale of affected users and resources;
  • financial, reputational, and infrastructure risk;
  • the presence of a practical rather than solely theoretical scenario.
The maximum program reward is up to RUB 50,000 before tax. Zero-day and one-day vulnerabilities for which an official patch was released less than a week ago are considered individually.

8. Duplicates

A reward is paid for the first report that contains sufficient information to reproduce and remediate a valid, previously unknown vulnerability.
Later reports may be closed as Duplicate when they describe the same root cause and add no independent impact necessary for remediation. Different payloads, parameters, or variants of one endpoint are not separate vulnerabilities when one fix addresses all variants.
Reports closed as Informational are assessed independently as Informational if no valid primary report with the same demonstrated vulnerability exists.

9. Disclosure

Do not disclose vulnerabilities, testing materials, technical details, or program data without written approval from the MyReviews team.

10. How to obtain testing funds

  1. Register your own test accounts.
  2. Send their IDs and a link to your verified Standoff365 profile to bugbounty@myreviews.ru.
  3. After the information is verified, the team may credit a bonus payment for testing.
Launched July 10, 10:59
Edited July 17, 13:35
Program format
Vulnerabilities
Reward for vulnerabilities
up to ₽50K
Excl. tax
Top hackers
Overall ranking
The ranking is still empty