Security Testing Rules of Engagement for netherportal3.com Published: 2026-09-07 Canonical: https://netherportal3.com/.well-known/security-policy.txt 1. AUTHORIZATION This document is the site operator's written authorization for good-faith security testing of the target in section 2, by the researcher or agent it was shared with. It is served from https://netherportal3.com/.well-known/security-policy.txt; because only the operator of netherportal3.com can publish a file at that path on that host, its presence here demonstrates control of the domain and stands as the authorization itself. The operator may revoke or change this authorization at any time by editing or removing this file. Re-read it before each testing session and treat the version served here as authoritative. 2. SCOPE (what you may test) The two platform sites, plus the operator-owned service hosts named below. Each platform site is reachable at both its apex and its "www" host, and https://netherportal3.com in fact redirects to https://www.netherportal3.com (both are the same site, and the "www" host is authorized). In scope: - https://netherportal3.com AND https://www.netherportal3.com, and the API endpoints served under them. - https://netherbio.com AND https://www.netherbio.com, and the API endpoints served under them. - The operator-owned service hosts named here, and the API endpoints served under them: - https://paste.netherbio.com Out of scope (not authorized, do not test): - Any host not named above. In particular, netherbio.com also hosts many customer sites on OTHER subdomains: every such subdomain is a separate customer or platform site, so do not test any *.netherbio.com host other than www and the operator hosts named above, and do not test tenant or customer bio sites, storefronts, or custom domains. - Third-party infrastructure and providers the site depends on (hosting, CDN, DNS, email, payment). If you suspect an issue there, report it to us and let us coordinate; do not test it directly. - Denial-of-service in any form: volumetric, stress, load, resource-exhaustion, or brute-force testing against production. Do not attempt to degrade availability for real users. - Social engineering, phishing, or physical attacks against the operator, staff, users, or infrastructure. - Sending spam or test traffic to real people: no mass or unsolicited email, no Discord message or ticket floods, no test messages to real users or staff. 3. RULES (how to test) - Use only test accounts and test data that you create. Do not access, modify, delete, or exfiltrate data belonging to real users, customers, tenants, or the operator. This includes account, profile, payment, payout, wallet, invoice, and configuration data. - Do not write to, alter, or destroy customer or production data. If you find a write or state-changing flaw, prove it with the least-impact demonstration you can (ideally a benign, reversible no-op) and stop. Do not run it at scale. - If you can reach another party's data, stop at a single record that proves access. Do not enumerate, download, or retain more, and report it right away. - Minimize impact. Prefer read-only proofs, throttle your own traffic, and back off if you see signs of user-facing disruption. - Our automated abuse protection may block or throttle the IP you test from. If you think that has happened, you may switch IP or use a proxy to keep testing in scope and to reach the reporting channel. Check in from the new IP (see section 4) so we can still attribute it to you. This is only to keep you unblocked for good-faith work; it is not permission for the volumetric or rate-limit testing that section 2 puts out of scope. - Stop and report on the first confirmed high-impact finding (remote code execution, authentication or authorization bypass, cross-tenant or cross-user data access, payment or payout manipulation, secret or credential exposure). Do not chain further, pivot, or escalate once one is proven. - Keep everything you find confidential. Do not disclose publicly until we have shipped a fix and agreed on disclosure timing with you. 4. REPORTING, AND IDENTIFYING YOUR TRAFFIC Before you start, register so we can tell your good-faith testing apart from a real attack: - Generate an engagement token: POST to https://netherportal3.com/api/security/engagement (a GET returns the format). It returns a token. You may send an optional short label. - From every IP or proxy you test from, POST that token to https://netherportal3.com/api/security/checkin before you start testing from it, so we associate that IP with you. Do this again from each new IP. - Put the token in the "x-engagement-token" header on every report. - Optional but helpful: send that same "x-engagement-token" header on ALL your testing requests, not just reports. We log tokened requests as they arrive, so we can watch and attribute your session live and keep it clear of a real attack. Send one report per finding, as early as you can confirm it. - Preferred: POST the finding to https://netherportal3.com/api/security/report. It accepts JSON and returns a reference number. A plain GET to that URL returns the exact field format. - Email security@netherportal3.com. This is the reliable channel. The endpoint returns a reference number only when a report is stored, so if you do not get one back, or for anything you consider important, email the report as well so it is sure to reach us. - For any high-impact finding, email security@netherportal3.com as well so a person is paged, then stop testing that issue. Include with each report: - A clear description of the issue and its concrete security impact. - Steps to reproduce: a proof-of-concept, the request and response, or a minimal script. - The affected URL, endpoint, or component, and any prerequisites (authentication, configuration, timing). - Your severity assessment and, if you have one, a suggested fix. - A contact so we can follow up and, with your permission, credit you. 5. WHAT TO EXPECT These are targets, taken seriously, not contractual guarantees: - Acknowledgment within three business days. - Triage and an initial severity assessment within seven business days. - Remediation prioritized by severity; critical issues are worked immediately. - Credit, with your permission, once a fix has shipped. 6. SAFE HARBOR We will not pursue or support legal action against a researcher who makes a good-faith effort to follow this policy, avoids privacy violations, data destruction, and service disruption, and gives us a reasonable chance to remediate before any public disclosure. If you are unsure whether something is authorized, ask at security@netherportal3.com before you do it. Acting outside the scope in section 2, or against the rules in section 3, is not authorized and is not covered by this safe harbor.