Responsible Disclosure Policy

We welcome reports from security researchers and from anyone who finds a weakness in estype. This policy explains what you may test, how to report what you find, what you can expect from us, and the protection we give you when you act in good faith.

estype is provided by ELIM GROUP LLC. By testing under this policy you agree to follow it and the law that applies to you.

1. How to report

Email security@estype.com, in English. One report per issue is easiest for us to track. If you are not sure whether something is a vulnerability, report it anyway.

We do not publish a PGP key yet. If your report contains something sensitive, such as data you came across, send a short first message without it and we will agree a secure way to receive the rest.

The same contact details are published in machine-readable form at /.well-known/security.txt.

2. What to include

A clear report gets a faster answer. The OpenSSF vulnerability report template is a good structure. Please include:

• the hostname, page or API endpoint affected;
• the type of issue and what an attacker could do with it;
• step-by-step instructions to reproduce it, with the requests and responses involved;
• a proof of concept, screenshots or a short video, if you have them;
• the workspace and account you tested with, so we can find your activity in our logs;
• how you would like to be credited, if at all.

3. Scope

These systems are in scope:

• estype.com, this website, including its contact form;
• app.estype.com, the sign-in and workspace application;
• api.estype.com, the estype API;
• *.app.estype.com, customer workspaces, but only a workspace that you own or that was created for your testing.

If you find an issue on another hostname that belongs to estype, write to us before you test it.

These are not in scope:

• websites that our customers build and publish, including those served from our hosting, unless the weakness is in estype itself rather than in the customer's own site;
• third-party services we use or that customers connect, such as Google Cloud, Cloudflare, Paddle, Slack or Notion, unless the issue is in how estype uses them. Report problems in those services to their owners;
• the Paddle checkout and the Paddle customer portal, which Paddle operates.

4. Rules for testing

• Use your own account and data. Test only against a workspace you own or one we set up for you. Never access, change or delete another customer's data. If you reach data that is not yours, stop, do not keep a copy, and tell us what you saw.
• Do not disrupt the service. No denial of service, no load or stress testing, and keep automated scanning gentle: a few requests a second at most. Stop if you notice the service slowing down.
• Do no harm beyond what proves the issue. Show that a weakness exists with the smallest possible step. Do not pivot from it into other systems, plant persistent access or exfiltrate data.
• No social engineering or physical attacks against our team, our customers or our providers, and no phishing or spam.
• Keep it confidential. Give us a reasonable time to fix the issue before you share it with anyone else (see section 7).
• We do not pay for testing. We do not refund subscription fees or other costs incurred while researching.

5. Findings we do not accept

We read every report, but the following are normally not treated as vulnerabilities unless you show a real impact on the security of estype or its customers:

• denial of service and resource exhaustion, and reports that only show a missing rate limit;
• brute-force attacks on sign-in or password reset, or the absence of an account lockout;
• missing security headers, cookie flags or best-practice settings with no demonstrated way to exploit them;
• the TLS versions or cipher suites we support, unless you show a practical attack;
• disclosure of software names, versions or public IP addresses;
• whether an email address has an account, learned from sign-in or invitation messages;
• clickjacking on pages with no sensitive action;
• self-XSS, or attacks that need the victim to paste code into their own browser;
• attacks that require physical access to a device, a compromised browser, or an unlikely series of actions by the victim;
• SPF, DKIM or DMARC settings, and spam sent through our contact form;
• results of automated scanners sent without confirming them by hand;
• vulnerabilities in outdated browsers or operating systems;
• social engineering of our team or our customers.

6. What you can expect from us

• Acknowledgement within 3 business days of your report, from a person, not an auto-reply.
• An initial assessment: whether we can reproduce the issue and how serious we think it is. We aim to send this within 10 business days.
• Updates as we work on it, and a message when the issue is fixed. How long a fix takes depends on the issue, so we do not promise a fixed date, but we fix serious issues first.
• Credit, if you want it. With your permission we will thank you by name when we describe the fix.

If a vulnerability affected customer data, we will tell the customers affected as our Data Processing Addendum and the law require.

7. Coordinated disclosure

Please do not share details of a vulnerability until we have fixed it, or until 90 days after your report, whichever comes first. If a fix needs longer, we will explain why and agree a new date with you. If you plan to publish, send us a draft first so we can check that it does not expose customer data.

8. Safe harbour

If you make a good-faith effort to follow this policy while researching and reporting:

• we consider your research authorised, and we will not take legal action against you or report you to law enforcement for it;
• we will not treat it as a breach of our Terms of Service for the account you tested with, to the extent the research was needed to find and show the issue;
• if someone else takes legal action against you for research that followed this policy, we will make it known that your research was authorised by us.

We cannot authorise testing of systems that belong to others, such as our providers or our customers' own websites, and this safe harbour does not cover them. If you are unsure whether something you plan to do follows this policy, ask us first at security@estype.com.

9. Rewards

We do not run a bug bounty programme and do not pay rewards for reports. We are a small team, and we would rather say so up front. What we can offer is a prompt, honest answer, a fix, and public thanks if you want it.

10. Your personal data

We use the details you send us, such as your name and email address, only to handle your report, to keep you updated and, if you agree, to credit you. We handle them as our Privacy Policy describes.

11. Changes to this policy

We may update this policy. The date at the top shows when the current version took effect. A report is handled under the version in force on the day you sent it.