Vulnerability Disclosure Policy
Effective Date: October 15, 2026 Version: 1.0 Applies to: All security researchers and Developers who identify or test for vulnerabilities in the Platform, whether or not the person holds an Account.
Article 1: Introduction and Scope
1.1 This Policy governs how vulnerabilities in the Platform are reported, how the Company responds, the testing the Company authorizes, and the protection the Company gives to good-faith research. This Policy is the only authorization to probe the Platform; a test not permitted by this Policy is not permitted at all.
1.2 This Policy covers the Platform's own systems and services: the websites and applications the Company operates, the application programming interface, and the configuration of the systems the Company controls, including access controls, authentication configuration, and storage configuration. If the Company owns the system and an attacker could reach it, the system is in scope.
1.3 The following are always out of scope: (a) social engineering of staff, Sellers, or Buyers, including phishing and pretexting; (b) denial-of-service testing of any kind, including slow-rate resource exhaustion, against any environment; (c) physical intrusion or facility testing; (d) third-party services the Company merely integrates, including a payment processor's own infrastructure and a supplier's own systems; (e) the Company's social media accounts; and (f) vulnerabilities in a researcher's own tools or in software the Company does not supply. A report against an out-of-scope target is closed with an explanation, not triaged.
1.4 If a provision of this Policy conflicts with the Terms of Use, this Policy controls for the subject it governs. A vulnerability that has been exploited is a breach, and from the moment evidence of exploitation appears the Breach Notification Requirements govern; this Policy governs reporting before that point.
Article 2: Definitions
2.1 Account: the account a person or business establishes with the Company to use the Platform.
2.2 Company: All About Pawz, LLC, a Tennessee limited liability company.
2.3 Developer: a person or business the Company has accepted to build on the Platform's application programming interface or to participate in a partner program.
2.4 Good-Faith Research: testing conducted entirely within the bounds of Article 4, reported promptly under Article 3, that accesses only what is needed to demonstrate the vulnerability and takes nothing beyond the minimum proof.
2.5 Platform: the websites, applications, and services the Company operates under the name All About Pawz, including aapawz.com.
2.6 Reporter: any person who submits a report under Article 3, whether or not the person holds a Developer account.
Article 3: Reporting a Vulnerability
3.1 A report shall be sent to legal@aapawz.com. The channel is confidential: the Company shall treat the report, the Reporter's identity, and all correspondence as non-public until the disclosure timeline in Article 6 completes.
3.2 A complete report contains: (a) the affected component, identified exactly: the route, function, or configuration concerned; (b) steps to reproduce, as a numbered sequence a competent engineer can follow to reach the same result, including the test account used; (c) impact: what an attacker gains, whose data becomes readable, and what actions become possible; (d) exploitation status: whether the Reporter believes the vulnerability is being exploited, and on what evidence; and (e) a remediation suggestion, where the Reporter has one, which is optional and always welcome.
3.3 A report in the form Article 3.2 states is triaged promptly. A report that does not identify a component or steps to reproduce receives one request for clarification; the report is not triaged until the clarification arrives.
3.4 Reports may be filed pseudonymously. A Reporter reporting an actively exploited or critical vulnerability shall mark the report "SECURITY: CONFIDENTIAL" in the subject line.
Article 4: Authorized Testing
4.1 Authorized testing is limited to: (a) testing against the Reporter's own Developer account and the Reporter's own Applications; (b) testing against the Sandbox environment within its published rate limits, as governed by the API Rate Limits and Quotas and the Sandbox Acceptable Use Policy; (c) automated scanning of the Reporter's own surfaces at a rate a person could sustain; and (d) read-only probing of public endpoints to confirm whether a vulnerability exists, provided the probing stays within rate limits and touches only data the Reporter is entitled to see.
4.2 The following are never authorized, whatever the intention: (a) accessing, modifying, or taking another tenant's data: tenant isolation is the bright line, and crossing it, even to prove a vulnerability, ends the safe harbor in Article 7 and is treated as unauthorized access under the Scraping Prohibition; (b) denial-of-service testing of any kind; (c) testing production payment flows with real payment instruments; (d) social engineering of any person; (e) brute-forcing session tokens or credentials at a rate that degrades service; and (f) pivoting from a confirmed vulnerability into adjacent systems. The Reporter shall demonstrate the vulnerability, stop, and report.
4.3 The minimum proof is enough. A vulnerability shall be demonstrated against the Reporter's own accounts. Reading a record belonging to another Seller to confirm an access-control defect is already past the line. Where a vulnerability can only be proven against third-party data, the report shall describe the theoretical impact without performing the act, and the Company shall reproduce the vulnerability internally.
4.4 Exceeding a published rate limit during research ends the safe harbor in Article 7 for the excess traffic only; the remainder of the report is still honored if the research was otherwise in bounds. Repeated or deliberate evasion of a rate limit ends the safe harbor entirely and is treated as circumvention under the Scraping Prohibition.
Article 5: The Company's Response Commitments
5.1 The Company shall acknowledge every report within two (2) business days and shall assign severity at acknowledgment, stating the severity and the reasoning. The Company shall update the Reporter at triage, when a fix is committed, and when the fix is deployed.
5.2 Severity is judged by what the vulnerability actually permits. The Company applies the following triage and remediation targets (a) Critical: remote code execution; authentication bypass; mass exposure of data across tenants; compromise of the payment path so that payments can be forged or double-counted. Triage within twenty-four (24) hours; remediation target seven (7) days.
(b) High: privilege escalation, including one Seller acting as another or reaching administrative functions; significant exposure of buyer personal data within one tenant; stored cross-site scripting that executes in another user's session; bypass of webhook signature verification. Triage within seventy-two (72) hours; remediation target thirty (30) days.
(c) Medium: reflected cross-site scripting requiring user interaction; disclosure of system internals without exposure of personal data; cross-site request forgery on non-destructive actions; rate-limit gaps that enable enumeration at low speed. Triage within seven (7) days; remediation target ninety (90) days.
(d) Low: verbose error messages, missing security headers, and theoretical issues with no demonstrated exploit path. Triage within fourteen (14) days; remediation in the next release cycle.
5.3 A Reporter who disagrees with an assigned severity may submit additional evidence for one re-assessment. A severity dispute does not pause the remediation clock.
5.4 An actively exploited vulnerability is fixed within seven (7) days of confirmation regardless of severity, with emergency deployment where the ordinary change process under the Deprecation and Breaking Changes Policy would otherwise delay the fix.
Article 6: Coordinated Disclosure
6.1 The standard timeline is ninety (90) days from the report to public disclosure by the Reporter. The Company may request one extension of thirty (30) days for a genuinely complex fix, stating what is complex and why ninety (90) days is insufficient; the Reporter may decline the extension.
6.2 The Company shall publish a security advisory at or before the time the fix deploys, crediting the Reporter by name or handle at the Reporter's choice, unless the Reporter opts out. An advisory describes the vulnerability class and the fix; an advisory does not publish exploit code.
6.3 The Reporter shall not disclose the vulnerability publicly before the timeline in Article 6.1 completes, without the Company's written agreement. Early disclosure ends the safe harbor in Article 7 for that report. The Company's failure to meet a remediation target does not by itself authorize early disclosure, but the Reporter may publish at day ninety (90) regardless of the state of the fix.
Article 7: Safe Harbor
7.1 Good-Faith Research within the bounds of Article 4 is not treated as a violation of the Scraping Prohibition, does not trigger enforcement under the Partner Suspension, Termination and Appeals, and is not referred to law enforcement. The safe harbor is not conditioned on the report being novel or on the vulnerability being real; a good-faith dead end is still good faith.
7.2 The safe harbor does not cover: (a) testing outside the bounds of Article 4; (b) failure to report within forty-eight (48) hours of discovering that a test crossed into another tenant's data: the clock starts at discovery, and the report shall state what was accessed and that the data has been deleted; (c) public disclosure before the timeline in Article 6 completes; and (d) use of knowledge of a vulnerability for any purpose other than reporting, including trading on the knowledge, selling it, or extorting the Company or any Seller. An extortion attempt is referred to law enforcement immediately and permanently ends any relationship with the Reporter.
7.3 A researcher who, during otherwise authorized testing, comes upon another tenant's data, stops immediately, deletes what was received, and reports within forty-eight (48) hours with a full account of what occurred keeps the safe harbor. Deliberate taking of data is distinguished sharply from accidental receipt followed by prompt report.
Article 8: Duplicate and Related Reports
8.1 The first report that describes a vulnerability with enough substance to reproduce it earns the credit under Article 6.2. A later report of the same root cause is marked duplicate and closed with thanks. Substance decides, not the timestamp alone: a vague early report does not block a complete later one.
8.2 Reports that describe different symptoms of one root cause are linked, not marked duplicate. The Company's advisory credits each Reporter whose report materially advanced the fix. A Reporter is told when the Reporter's report is linked or marked duplicate, and why.
Article 9: Liability
9.1 Exclusion of certain damages. To the fullest extent permitted by law, neither party is liable to the other for indirect, incidental, special, punitive, or consequential damages, or for lost profits, lost revenue, or loss of goodwill, arising out of or relating to this Policy, even if the party has been advised of the possibility of those damages.
9.2 Cap. To the fullest extent permitted by law, the Company's total liability arising out of or relating to this Policy shall not exceed the greater of (a) the amounts the Reporter paid to the Company under this Policy in the twelve months before the event giving rise to the claim, or (b) one hundred dollars ($100).
9.3 Carve-outs. This Article does not limit (a) a party's indemnification obligations under this Policy; (b) liability for fraud or willful misconduct; (c) amounts owed for Orders, fees, chargebacks, or refunds under the Company's documents; or (d) liability that cannot be limited under applicable law.
9.4 Essential purpose. The parties agree that this Article allocates risk between them, that it is an essential part of the basis of their bargain, and that it applies even if a limited remedy fails of its essential purpose.
Article 10: Indemnification
10.1 Duty. A Reporter who holds a Developer account shall indemnify, defend, and hold harmless the Company and its members, managers, employees, and agents from and against every claim, demand, action, loss, liability, judgment, settlement, cost, and expense (including reasonable attorneys' fees) arising out of or relating to: (a) the Reporter's breach of this Policy; (b) the Reporter's Applications, services, listings, or content; (c) the Reporter's violation of any law or of the rights of any person; and (d) taxes for which the Reporter is responsible under the Company's documents.
10.2 Procedure. The Company shall give prompt written notice of a claim under this Article. The indemnifying party shall control the defense with counsel reasonably acceptable to the Company. The Company may participate in the defense at its own expense. The indemnifying party shall not settle a claim in a manner that imposes any obligation or restriction on the Company, or that does not release the Company fully, without the Company's prior written consent.
10.3 Survival. This Article survives the termination of this Policy.
Article 11: Enforcement and Appeals
11.1 Investigation. The Company may investigate any suspected violation of this Policy. A Developer under investigation shall cooperate with the investigation and shall produce the records the Company's documents require the Developer to keep.
11.2 Notice. If the Company determines that a Developer has violated this Policy, the Company shall give written notice stating the provision violated and the facts relied on, except where notice would compromise an investigation of fraud, a safety risk, or a legal obligation. Research within the safe harbor in Article 7 is not a violation and is not the subject of a notice under this Article.
11.3 Opportunity to cure. Where a violation is capable of cure, the Developer has ten (10) business days from notice to cure it and to confirm the cure in writing. No cure period applies to fraud, unauthorized access outside Article 4, a safety risk, unlawful conduct, or a violation that by its nature cannot be cured.
11.4 Measures. If a violation is established and is not cured within the period allowed, the Company may, proportionate to the violation: (a) issue a written warning; (b) suspend the Developer's Credentials or program participation, in whole or in part; (c) terminate this Policy and the Account; and (d) exercise any other right or remedy available under this Policy or at law. Procedure for suspension, termination, and credential measures is governed by the Partner Suspension, Termination and Appeals.
11.5 Appeal. The Developer may appeal a measure under this Article by written notice to legal@aapawz.com within thirty (30) days of the measure, stating the grounds and attaching the records relied on. The appeal is decided by a person who did not make the original decision. The Company's decision on appeal is final. A measure remains in effect during an appeal unless the Company directs otherwise in writing.
11.6 No waiver by delay. The Company's delay in acting on a violation is not a waiver of the violation or of any later violation of the same kind.
Article 12: Term and Termination
12.1 Term. This Policy takes effect when a person first tests or reports under it and continues until terminated under this Article.
12.2 Termination by the Company. The Company may terminate this Policy as it applies to a Developer, and the Account, on thirty (30) days' written notice for any reason, and immediately on written notice if the Developer materially breaches this Policy or engages in fraud or unauthorized access. Termination of this Policy does not withdraw the safe harbor in Article 7 for Good-Faith Research completed before termination.
12.3 Termination by the Developer. A Developer may terminate this Policy as it applies to the Developer on thirty (30) days' written notice to support@aapawz.com, provided the Developer has no investigation outstanding.
12.4 Effect of termination. On termination: (a) the authorization in Article 4 ends; (b) obligations that arose before termination: including the disclosure timeline in Article 6 for a report already filed, record-keeping, and indemnification obligations: survive until satisfied.
12.5 Survival. The Definitions, Liability, Indemnification, Enforcement and Appeals (for measures taken before termination), Dispute Resolution, and General Provisions Articles survive termination.
Article 13: Dispute Resolution
13.1 Any dispute arising out of or relating to this Policy, or to the relationship it governs, is governed by the Dispute Resolution Policy, which is incorporated into this Policy by reference.
Article 14: General Provisions
14.1 Amendments. The Company may amend this Policy by posting the amended Policy in the Document Center and giving notice to affected Developers at the email address in the Account. An amendment that materially increases a Developer's obligations takes effect thirty (30) days after notice; other amendments take effect on posting. A Reporter's report is governed by the version of this Policy in effect when the report is filed.
14.2 Notices. Reports under Article 3 and legal notices under this Policy shall be sent to legal@aapawz.com. Operational notices and all other communications shall be sent to support@aapawz.com. A notice to the Company is effective when the Company acknowledges receipt or, for email, one business day after sending, whichever is earlier. Notices to a Developer are effective when sent to the email address in the Account or posted to the Account's notice facility in the portal, whichever occurs first. The Developer shall keep the email address in the Account current.
14.3 Governing law. This Policy is governed by the laws of the State of Tennessee, without regard to its conflict-of-laws rules. Subject to the Dispute Resolution Policy, any proceeding arising out of this Policy shall be brought in the state or federal courts located in Shelby County, Tennessee, and the parties consent to personal jurisdiction there.
14.4 Severability. If any provision of this Policy is held unenforceable, the provision shall be enforced to the fullest extent permitted, and the remaining provisions continue in full effect.
14.5 Entire agreement. This Policy, together with the documents it incorporates by reference, is the entire agreement between the Company and each Reporter for the subject it governs and supersedes every prior or contemporaneous statement, communication, or agreement on that subject, whether written or oral.
14.6 Assignment. A Developer shall not assign this Policy or any right or obligation under it without the Company's prior written consent, and an assignment without consent is void. The Company may assign this Policy to an affiliate or in connection with a sale of all or part of its business, on notice to affected Developers.
14.7 Waiver. A waiver of any provision of this Policy is effective only in writing and only for the instance stated. No waiver is a waiver of any other provision or instance.
14.8 Interpretation. Headings are for convenience only. "Including" means "including without limitation." This Policy shall not be construed against a party as its drafter. The English-language text controls over any translation.