Appsamurai Vulnerability Disclosure

generated: '2026-08-13'
method: probed
found: false
credited: false
source: >-
  live probes of appsamurai.com, api.appsamurai.com, storyly.io, www.storyly.io,
  api.storyly.io, docs.storyly.io, mcp.storyly.io, dashboard.storyly.io
  (2026-08-13) + https://appsamurai.com/information-security-policy/
notes: >-
  App Samurai publishes NO vulnerability disclosure programme. This file exists
  to record that, and to correct a false positive.
  The automated probe initially reported a policy at
  bugcrowd.com/resource/standard-disclosure-terms and contacts
  bugcrowd.com/intercom and security@intercom.com. Those are INTERCOM's - the
  security.txt harvested in round 1 came from help.appsamurai.com, App Samurai's
  Intercom-hosted help centre CNAME, and its own Canonical field points at
  https://app.intercom.com/.well-known/security.txt. It is a vendor document
  reached through a customer's subdomain, not an App Samurai commitment. Reporting
  an App Samurai vulnerability to security@intercom.com would go to the wrong
  company. The finding is therefore rejected and no Security or SecurityTxt
  pointer is emitted in apis.yml.
  For the same reason help.appsamurai.com now 308-redirects to
  appsamurai.com/help/, so that security.txt is no longer served at all.

rejected_findings:
  - source: well-known/appsamurai-security.txt
    claimed_policy: https://www.bugcrowd.com/resource/standard-disclosure-terms/
    claimed_contacts:
      - https://bugcrowd.com/intercom
      - mailto:security@intercom.com
    owner: Intercom
    canonical: https://app.intercom.com/.well-known/security.txt
    reason: Vendor security.txt served through App Samurai's help-centre CNAME. Not App Samurai's programme.

probes:
  - {url: 'https://appsamurai.com/.well-known/security.txt', status: 404}
  - {url: 'https://api.appsamurai.com/.well-known/security.txt', status: 500}
  - {url: 'https://www.storyly.io/.well-known/security.txt', status: 404}
  - {url: 'https://storyly.io/.well-known/security.txt', status: 404}
  - {url: 'https://api.storyly.io/.well-known/security.txt', status: 404}
  - {url: 'https://docs.storyly.io/.well-known/security.txt', status: 404}
  - {url: 'https://mcp.storyly.io/.well-known/security.txt', status: 404}
  - {url: 'https://dashboard.storyly.io/.well-known/security.txt', status: 200, result: spa-shell}
  - {url: 'https://appsamurai.com/security/', status: 404}
  - {url: 'https://www.storyly.io/security', status: 404}
  - {url: 'https://www.storyly.io/trust', status: 404}

bug_bounty:
  hackerone: none
  bugcrowd: none
  intigriti: none

security_contact:
  published: false
  note: >-
    No security@ address, no disclosure page and no reporting route is published
    on either brand. The Information Security Policy
    (https://appsamurai.com/information-security-policy/, HTTP 200) tells
    EMPLOYEES to report suspected breaches internally; it gives an external
    researcher nowhere to go.

what_exists_instead:
  - url: https://appsamurai.com/information-security-policy/
    status: 200
    kind: information security management policy
    legal_entity: Apps Medya Teknoloji A.S.
    note: >-
      An ISMS policy statement, consistent with the ISO 27001 claim recorded in
      conformance/appsamurai-conformance.yml. It is a governance document, not a
      disclosure programme.

recommendation_for_provider: >-
  A three-line /.well-known/security.txt on appsamurai.com and storyly.io naming
  a real App Samurai contact would close this gap outright, and would also stop
  scanners attributing Intercom's programme to App Samurai.