We take reports of security vulnerabilities seriously and will work with you to understand and resolve them quickly. This policy applies to MercaMap: the mobile app, its backend, the staff console, the brand portal at mercamap.com, and our source repository. It is published at https://mercamap.com/security, the address security.txt gives in its Policy field.
Reporting a vulnerability
- Email: seguridad@mercamap.com (also published at https://mercamap.com/.well-known/security.txt). Reports in Spanish or English.
- Please include: a description of the issue, steps to reproduce or a proof of concept, the affected component (app version, API route, admin page), and any logs or screenshots. Do not include personal data of other users in the report.
- We acknowledge reports within 3 business days, give a first assessment within 10 business days, and keep you informed while we fix the issue. Target fix times follow severity: critical within 7 days, high within 30 days, others in the next release.
- We ask for coordinated disclosure: please give us up to 90 days from acknowledgement before publishing details. We will credit you in the release notes if you wish.
- We do not run a paid bug bounty at this time.
Scope
In scope:
- The mobile app (iOS and Android) and its communication with the backend.
- The backend API, durable workflows, public pages, the staff console and the brand portal hosted on Vercel.
- This repository: CI workflows, dependency configuration, scripts under
tools/.
Out of scope:
- Volumetric attacks, denial of service or rate-limit exhaustion (they are also prohibited by our hosting provider's terms).
- Social engineering, phishing of our team or of users, physical attacks.
- Infrastructure operated by third parties (Vercel, Supabase, Expo, Resend, ImprovMX, Sentry, PostHog, Better Stack, app stores). Please report those to the provider concerned.
- Findings that require a rooted or jailbroken device, or a malicious app already installed on the same device.
- Reports from automated scanners without a demonstrated impact; missing best-practice headers without an exploit path; outdated dependency versions without a reachable vulnerability.
Rules for testing
- Only test against accounts and data you own or that we have provided for testing. Never access, modify or delete other people's data; if you encounter it, stop and report.
- Do not attempt to film in stores, upload real frames of people, or use the mapper flow with third parties for testing purposes; use the demo store and fake data.
- No denial of service, no spam, no social engineering, no physical intrusion.
- Do not exfiltrate data beyond what is needed to demonstrate the issue; delete it once the report is acknowledged.
Safe harbour
If you make a good-faith effort to comply with this policy while researching and reporting, we consider your research authorised. We will not initiate or support legal action against you for accidental, good-faith violations of this policy, and we will not report you to the authorities for activity that stays within it. If legal action is initiated by a third party against you for activity conducted within this policy, we will make it known that your actions were conducted in compliance with it. This authorisation does not extend to third-party systems listed as out of scope; contact those providers directly. Access outside this policy may be unlawful under Spanish law (Código Penal art. 197 bis and following), so please stay within it. If you are unsure whether something is covered, ask us first.
Our commitments
- We follow a documented security programme: a STRIDE threat model, the OWASP ASVS 5.0 Level 2 checklist, quarterly self-assessments that list every open finding with its due date, checks on every push of code (a secrets scan of the whole history, a dependency audit, the EU data-residency and AI-model policy checks), a weekly static analysis, and an external penetration test before the first paid customer (decision D-53). The documents are in our repository (
docs/security/). - Personal-data incidents are handled under our breach procedure with notification to the AEPD within 72 hours where required (
docs/runbooks/breach.md). - We publish backend fixes as deployments, which reach production as soon as their checks pass (there is no staged rollout), and app fixes as new builds through the app stores.
Thank you for helping keep mappers, shoppers and bystanders safe.