Security Policy

What To Include

Please include enough detail for reliable triage:

• A clear description of the issue and impact
• Exact URL(s), endpoint(s), or component(s) affected
• Reproduction steps and any prerequisites
• Proof of concept, logs, or screenshots (when safe to share)
• Your contact information for follow-up

Scope

This policy applies to internet-facing assets owned and operated by IT Help San Diego Inc.:

If you report an issue in third-party infrastructure, include evidence showing how it directly affects our operated assets.

If your assessment is part of a formally authorized program (government, regulatory, or contracted), include the authorization reference so we can route it correctly.

Authorized Security Testing

IT Help San Diego participates in recurring external security assessments, including CISA Cyber Hygiene scanning and other explicitly authorized testing engagements.

Activities that may otherwise be out of scope are permitted when authorization exists in writing (for example: program agreement, statement of work, or rules of engagement).

Authorized testing may include:

• Phishing or social engineering exercises
• Red-team activity
• Controlled active testing that is agreed in advance

For authorized engagements, follow the signed rules of engagement and designated escalation channels.

Safe Harbor

This policy does not limit or override permissions granted under separate written government, regulatory, or contractual testing agreements.

Good-faith testing means:

• Avoiding privacy violations, data destruction, and service disruption
• Accessing only the minimum data required to demonstrate the issue
• Stopping testing after obtaining proof and reporting promptly
• Not sharing, retaining, or reusing any non-public data

Out of Scope

The following are generally out of scope unless there is demonstrable business impact:

• Social engineering, phishing, or red-team activity without explicit written authorization
• Physical attacks or local network attacks requiring physical access, unless expressly authorized in writing
• Denial-of-service (DoS/DDoS), traffic flooding, or resource exhaustion testing, unless expressly authorized in writing with defined scope, windows, and safeguards
• Vulnerabilities that depend on outdated/unpatched client software with no direct server-side impact
• Reports without reproducible evidence
• Findings from domains analyzed by DNS Tool (those belong to their respective owners)

Response Targets

Remediation timeline is risk-based and dependent on complexity. We will keep you informed throughout the process.

Public Disclosure

Please do not publicly disclose vulnerabilities until remediation is complete or a coordinated timeline is agreed upon in writing.

Bug Bounty

IT Help San Diego Inc. does not currently operate a paid bug bounty program.

Privacy Pledge

We run a consultancy serving high-profile clients. They hear from us when we answer their questions, send their invoices, or confirm their appointments. That’s it. No newsletters, no promotions, no noise. That same discipline applies here.

• No marketing email — we don’t send newsletters, promotions, or drip campaigns.
• No mailing lists — signing in does not subscribe you to anything.
• No account required — every core analysis works without logging in. If you choose to sign in via Google, we store only your name and email for authentication.
• Service-critical notices only — if we ever need to contact you (security advisory, breaking change, or account issue), it will be rare, justified, and directly relevant to your use of the tool.
• Opt-in only — if we add product update notifications in the future, they will require your explicit consent and can be disabled at any time.
• No third-party data sharing — your information stays here. We don’t feed it to analytics platforms, ad networks, or data brokers.

This pledge reflects our current practices. If our business model evolves, any changes to communication practices will require your explicit opt-in consent.

Security Practices

DNS Tool is built with security as a core principle:

• Google OAuth 2.0 with PKCE — no passwords stored, no credentials to compromise
• No tracking cookies — minimal data collection reduces attack surface
• Content Security Policy (CSP) with per-request nonces on all pages
• CSRF protection on all state-changing operations
• Rate limiting to prevent abuse
• SSRF hardening — internal network ranges blocked on outbound requests
• Input validation — domain names validated and sanitized before processing
• HTTPS enforced with HSTS and secure headers
• Open-core — application framework is publicly available for review on GitHub under BUSL-1.1

security.txt

Machine-readable reporting details are published at:

• https://dnstool.it-help.tech/.well-known/security.txt
• https://dnstool.it-help.tech/security.txt
• https://www.it-help.tech/.well-known/security.txt
• https://www.it-help.tech/security.txt