Security Policy

Last updated: February 17, 2026

Trust Statement

SHRTX is built with a local-first model. Most tools process data directly in your browser, and we avoid sending tool input to our servers unless a specific feature explicitly requires a remote API call.

We aim to keep user trust through the following principles:

• Privacy by default: no account required to use core tools.
• Local processing first: file/text processing is browser-side unless clearly stated otherwise.
• Consent-aware analytics: analytics is controlled by user consent settings.
• Non-deceptive monetization: ads are never disguised as product controls, download buttons, or tool output.
• Transparent behavior: when a tool needs external network access, it should be visible and intentional.

Policy Alignment

Security commitments are backed by the following public policy documents:

• Privacy Policy: https://shrtx.in/privacy
• Terms of Service: https://shrtx.in/terms
• Disclaimer: https://shrtx.in/disclaimer
• Advertising Policy: https://shrtx.in/advertising
• Sponsorship Policy: https://shrtx.in/sponsorship

If there is any conflict between this document and runtime behavior, report it as a security/trust issue.

Machine Learning and Language Model Assisted Engineering

SHRTX is maintained by an independent developer and may use machine learning (ML) and large language model (LLM) systems to assist with engineering tasks such as implementation support, debugging guidance, documentation drafting, and test planning.

Boundary commitments:

• These systems are used as engineering assistance, not autonomous security decision-makers.
• Core local-first tool inputs are not intentionally sent to ML/LLM systems during normal tool usage.
• Human review remains required for security-sensitive code and policy changes before release.
• Users should avoid sending highly sensitive personal data in support or vulnerability reports unless required for reproduction.

Reporting a Vulnerability

If you discover a security issue, report it privately:

• Email: contact@shrtx.in
• Subject: Security Report: <short summary>

Please include:

• Affected URL/tool
• Reproduction steps
• Impact assessment
• Any proof-of-concept details
• If related to ads or monetization behavior, include screenshot + page URL so we can trace the ad source.

Response Expectations

• Initial acknowledgement target: within 72 hours
• Triage/update target: within 7 days
• Fix timeline: depends on severity and complexity

If the issue is valid, we will prioritize remediation and credit your report (if you want attribution).

Disclosure Guidelines

Please avoid public disclosure until a fix is released or we agree on a coordinated disclosure timeline.

Do not:

• Access, modify, or destroy user data
• Run denial-of-service tests
• Use social engineering, phishing, or physical attacks

Scope

In scope:

• shrtx.in web app behavior
• Client-side tool execution paths
• Frontend input handling and rendering issues
• Security-related misconfiguration in repository-controlled code
• Admin dashboard and API behavior (/admin, /api/admin/*) under repository control

Out of scope:

• Third-party platforms/services outside repo control
• Issues requiring compromised user devices/extensions
• Low-risk UX-only issues without security impact

Security Practices

• Dependency updates and build validation (npm run build)
• Type and runtime checks before release
• Ongoing hardening for link handling, content rendering, and form abuse protections
• Spreadsheet parsing hardening:
  • Removed xlsx from runtime dependencies
  • Browser-only Excel parsing uses lazy-loaded read-excel-file
  • PDF -> Excel export generates .xlsx locally via jszip
• First-party usage counter controls with strict slug validation and session-token-gated increments
• Edge abuse dampening and cache strategy for counter endpoints:
  • POST /api/increment: no-store
  • GET /api/count: short-lived public cache (max-age=60)
• Data minimization in counter storage: aggregate counts only (no tool input, IP address, or user-agent persisted in D1)
• Admin API hardening model:
  • Logical namespace enforcement for /api/admin/* inside Worker routing
  • Production hostname allowlist enforcement (shrtx.in, www.shrtx.in) with localhost allowed in dev
  • Cloudflare Access enforced at edge for /admin and /api/admin/* with worker-side JWT assertion validation for defense-in-depth
  • Strict prepared-statement D1 query usage for admin analytics endpoints
• Build hygiene:
  • Targeted suppression of the known onnxruntime-web Rollup EVAL warning only
  • All other build warnings continue to surface normally

Notes

SHRTX currently does not run a paid bug bounty program. Responsible reports are still welcome and appreciated.