Appearance

Security Policy ​

Effective Date: 2026-07-09 · Document ID: SP-MMA-001 · Contact: info@mapsted.com · Contact UsVersion: 1.0

Contact: security@mapsted.com · info@mapsted.com (fallback)

Scope of descriptions: The descriptions in this document are informational. Binding security commitments are set out exclusively in the signed Commercial Agreement between Mapsted Corp. and the Licensee.

1. Our Commitment ​

Mapsted Corp. takes the security of its products and customer data seriously. We welcome reports from security researchers who identify vulnerabilities in the Software or Mapsted's supporting infrastructure. We are committed to working with researchers in good faith and to responding promptly to credible reports.

Mapsted Corp. maintains an Incident Response Plan (IRP) covering vulnerability triage, containment, remediation, and post-incident review for confirmed security incidents affecting the Service. The IRP governs internal escalation, containment, and customer notification procedures. Specific notification obligations owed to Licensees are governed by the signed Commercial Agreement.

2. Scope ​

This policy covers vulnerabilities in:

  • The @mapsted/maps-js-api npm package and CDN bundle, including supply-chain integrity of assets delivered from mapi.mapsted.com.
  • Mapsted's backend services that the Software depends on:
    • mapi.mapsted.com — Software delivery and CDN
    • maps.mapsted.com — map rendering iframe
    • deploy.mapsted.com — building data delivery
    • filer.mapsted.com — asset file storage and delivery
  • This documentation site: docs.mapsted.com/maps-js-api.
  • API-key compromise: unauthorised disclosure of, or access to, Licensee API keys issued by Mapsted Corp. is an in-scope report class.

postMessage scope boundary: The maps.mapsted.com iframe communicates with the host page exclusively via window.postMessage. Security issues in the origin-validation logic within that iframe, or in the Software's postMessage event listener on the Licensee embedding page, are in scope. Security issues arising solely from the Licensee's own embedding-page code are out of scope and should be reported to the relevant Licensee.

3. Out of Scope ​

The following are out of scope for this policy:

  • Applications, websites, or kiosk deployments built by Licensees embedding the Software. Report those to the relevant Licensee directly.
  • Physical security of Mapsted Corp.'s premises.
  • Social-engineering attacks against Mapsted Corp. employees.
  • Denial-of-service attacks or resource-exhaustion testing against any Mapsted infrastructure.
  • Vulnerabilities requiring physical access to a device.
  • Vulnerabilities in third-party dependencies that Mapsted Corp. does not control, unless you can demonstrate exploitability in the context of the Software.
  • Issues in end-of-life or deprecated versions of the Software (v2 and v3 receive critical security fixes only; for the purposes of this policy, "critical" means a CVSS v3.1 base score of 9.0 or higher, or a CVSS v2.0 base score of 7.0 or higher; 4.0.1 is the supported release).

Testing techniques that are always out of scope regardless of target:

  • Automated scanning tools run against production infrastructure without prior authorisation.
  • Accessing, modifying, or exfiltrating data belonging to other Mapsted customers.
  • Any testing that degrades service for other users.

4. How to Report ​

To report a suspected vulnerability, email security@mapsted.com with:

  1. A clear description of the vulnerability, including the affected component or endpoint.
  2. Steps to reproduce, including any proof-of-concept code or screenshots.
  3. Your assessment of the potential impact and severity.
  4. Your contact details so we can follow up.

Please do not disclose the vulnerability publicly until we have had a reasonable opportunity to investigate and remediate it. See Section 6 for our coordinated-disclosure timeline.

PGP encryption: Mapsted Corp. will publish a PGP public key for encrypted security reports at /.well-known/security.txt as part of the pre-publish operational checklist. Until that key is published, send vulnerability reports via info@mapsted.com clearly marked for the security team.

RFC 9116 security.txt: Mapsted Corp. will publish an RFC 9116-conformant security.txt file at docs.mapsted.com/.well-known/security.txt as part of the pre-publish operational checklist.

5. Safe Harbour ​

Mapsted Corp. will not pursue legal action against security researchers who, acting in good faith — meaning with no intent to cause harm, with no intent to exploit the vulnerability for unauthorised commercial exploitation, and after prior notification to Mapsted Corp. in accordance with Section 4 — comply with all of the following conditions:

  1. Researchers should discover and report vulnerabilities in accordance with this policy.
  2. Researchers should make every reasonable effort to avoid privacy violations, degradation of service, disruption to production systems, and unauthorised access to or modification of data. Incidental, non-material access that is genuinely necessary to demonstrate the vulnerability does not, by itself, defeat safe-harbour protection.
  3. Researchers should limit data access to the minimum necessary to demonstrate the vulnerability and should not retain, share, or destroy data accessed during research.
  4. Researchers should not exploit the vulnerability for unauthorised commercial exploitation, nor use it to harm Mapsted Corp. or its customers. This condition is not intended to prevent researchers from publishing findings in academic papers, conference presentations, or responsible-disclosure write-ups following coordinated disclosure under Section 6.

Safe-harbour protection under this policy does not apply to conduct that violates the prohibitions in Section 3 of this policy, including but not limited to running automated scanning tools against production infrastructure without prior written authorisation, accessing other customers' data, or degrading service to other users.

Applicable law acknowledgement: Researchers are reminded that security testing may engage provisions of applicable law regardless of safe-harbour commitments by Mapsted Corp., including without limitation: the Computer Fraud and Abuse Act (18 U.S.C. § 1030) (United States); the Canadian Criminal Code s. 342.1 (Unauthorised Use of Computer) and s. 430(1.1) (Mischief to Data) (Canada); and equivalent statutes in other jurisdictions. Mapsted Corp.'s safe-harbour commitment is limited to its own claims and does not grant immunity from prosecution by third parties or government authorities.

6. Response Timeline ​

Mapsted Corp. aims to follow this timeline for credible, in-scope reports:

MilestoneTarget
Acknowledgement of receipt5 business days
Initial triage and severity assessment10 business days
Resolution or remediation plan communicated to reporter90 days for Critical/High (CVSS v3.1 base score ≥ 7.0); 180 days for Medium/Low (CVSS v3.1 base score < 7.0)
Public disclosure (coordinated with reporter)90-day embargo from date of acknowledgement, extensible by mutual agreement for complex vulnerabilities

These timelines are targets, not guarantees. Complex vulnerabilities may require additional time. We will keep reporters updated on progress.

GCP incident response and CDN patch delivery: Mapsted Corp.'s backend services run on Google Cloud Platform (GCP). For confirmed vulnerabilities affecting CDN-delivered assets, Mapsted Corp. will follow its IRP and will communicate a patch delivery timeline to affected Licensees. Licensees who pin to a specific CDN bundle version should monitor security advisories and update their pinned version promptly following a security release.

Vulnerability report data retention: Mapsted Corp. retains vulnerability report records (including correspondence and remediation evidence) for thirty-six (36) months following closure of the report.

7. Data Security Posture ​

The following describes Mapsted Corp.'s general data security posture for the Service. Specific commitments are governed by the signed Commercial Agreement.

  • All data in transit between end-user browsers and Mapsted's backend services is encrypted using TLS 1.3 preferred; TLS 1.2 minimum. TLS 1.0 and 1.1 are not supported.
  • Mapsted Corp.'s backend services hosted on GCP store data in the region(s) configured for the applicable GCP project (us-central1, us-east1 (United States); northamerica-northeast1, northamerica-northeast2 (Montréal, Toronto)).
  • Data at rest on Mapsted-operated infrastructure is encrypted using AES-256 via the Google Cloud Platform default encryption service.
  • Licensee API keys ("access keys") are transmitted from the host page to the Mapsted Maps iframe runtime over a dual-path transport during the current transitional grace window: (i) the legacy URL ?key=… query parameter on the iframe src, and (ii) a postMessage AUTH payload sent immediately after the iframe load handshake. The postMessage AUTH path was introduced in the current release, 4.0.1, to remove the access key from browser history, Referer headers, and intermediate access logs. Both transports converge on the same access key today; the URL transport is scheduled for removal in the iframe-side rollout (documented in the @mapsted/maps-js-api CHANGELOG). Outside this transitional window, Mapsted Corp.'s operational intent is that access keys are not embedded in URL query strings or logged in plaintext by Mapsted-operated services. Specific representations and warranties are governed by the signed Commercial Agreement and the Data Processing Addendum.
  • Mapsted Corp. uses the OWASP Top 10 as an internal reference framework for web application security development and review.

8. Acknowledgements ​

Mapsted Corp. thanks security researchers who responsibly disclose vulnerabilities in accordance with this policy. Recognition is handled privately unless the researcher requests public acknowledgement.