Skip to main content
Back to Home

Trust & Transparency

Security & Privacy

Last updated: July 11, 2026

How we protect your data and your code

What we never do

Never store your source code

Your code is scanned entirely in memory during the analysis request. Once the scan completes, the file contents are discarded immediately. Nothing is written to disk or persisted in our database.

Never write to your repositories

UNPWNED operates in read-only mode. We fetch file contents for analysis, but we never create commits, push branches, open pull requests, or modify anything inside your repositories.

Never sell your data

Your scan results, repository names, and account details are never sold, rented, or shared with advertisers or data brokers. Public checks may show limited domain lookup data such as severity counts and finding titles. Score and grade are shown only when scanner coverage supports a reliable result. Domain owners can request removal from Public Lookup.

How we protect your data

Two-factor authentication (MFA)

UNPWNED supports TOTP-based two-factor authentication via authenticator apps (Google Authenticator, Authy, etc.). MFA is enforced for all admin accounts - no exceptions.

GitHub tokens encrypted at rest

Your GitHub access token is encrypted with AES-256-GCM before being stored in our database. The encryption key is derived from a secret that lives outside the database, so a database breach alone cannot expose your token.

Row-level security on every table

Every database table uses operation-specific RLS policies. Users can only access their own data. Critical tables like subscriptions and usage tracking are read-only for users, with database triggers as a second defense layer.

SSRF protection on all outbound requests

Every URL that UNPWNED fetches on your behalf is validated against a blocklist of private IP ranges, cloud metadata endpoints (169.254.169.254, etc.), and loopback addresses. This prevents server-side request forgery attacks that could expose internal infrastructure.

Rate limiting with persistent storage

Login and signup requests are rate-limited per IP and per email using a three-tier system (Redis, database, in-memory fallback). Limits are enforced at the API layer before any expensive operations are triggered.

No secrets sent to AI providers

Raw scanner output is sanitized before processing. The AI model receives only technical security findings and metadata (domain, vulnerability names, severity, security header names and values, detected technologies, CVE/CVSS scores) and never secrets, credentials, or personal data.

GitHub Permissions Explained

Why we request the repo scope

GitHub's OAuth system does not offer a dedicated read-only scope for private repositories. The repo scope is the only way to read private repository file contents. It also technically grants write access, which GitHub cannot currently separate.

UNPWNED uses this scope exclusively to fetch file contents for security analysis. Our API routes only call GitHub's read endpoints (contents, trees). No write operations are ever performed: no commits, no pushes, no branch creation.

What we call

  • +GET /repos/{owner}/{repo}/contents/{path}
  • +GET /repos/{owner}/{repo}/git/trees/{sha}
  • +GET /user/repos (to list your repositories)

What we never call

  • -POST /repos/{owner}/{repo}/git/commits
  • -PUT /repos/{owner}/{repo}/contents/{path}
  • -POST /repos/{owner}/{repo}/pulls

Two Scanners, Two Angles

UNPWNED ships two distinct scanners. They look at your security from opposite directions and are kept separate on purpose. You can run either one on its own, or both together for full coverage.

Section A · Outside-In

What the live-domain scanner checks

Point UNPWNED at any URL and it runs 700+ checks across 40 scanners. We see what an attacker sees from the outside. We don't have access to your source code or your node_modules, so this scanner is entirely traffic-based: requests, responses, and what your live site exposes.

Categories covered

  • +SSL/TLS certificates and ciphers
  • +Security headers (CSP, HSTS, X-Frame-Options)
  • +DNS and email security (SPF, DKIM, DMARC, DNSSEC)
  • +Exposed sensitive files (.env, /debug, /actuator)
  • +Hardcoded secrets in live HTML, JS, and source maps
  • +Cookie security flags and CORS misconfiguration
  • +Open ports and exposed services
  • +Privacy compliance (cookie banners, policy pages)
  • +Error disclosure and stack-trace leakage
  • +Unauthenticated API endpoint discovery
  • +Supabase / Firebase public bucket exposure
  • +CVE fingerprinting on detected library versions
  • +SEO cloaking and ghost-page detection (Deep Scan)
  • +Form security and open-redirect detection (Deep Scan)

Section B · Inside-Out

Pro

What the GitHub repo scanner checks

Connect your repo to scan code-level issues we can't see from the outside. UNPWNED uses GitHub OAuth (read-only) to fetch file contents and run scheduled scans. Findings can auto-create GitHub Issues with copy-paste fix prompts.

Categories covered

  • +Dependency CVEs in package.json / lock files (npm, pip, cargo, gem, go.mod)
  • +Secret scanning across files and commit history (34+ patterns)
  • +Exposed environment files committed to the repo (.env, .env.production)
  • +Exposed credentials and key files (credentials.json, id_rsa, wp-config.php)
  • +Misconfigured GitHub Actions workflows (unpinned actions, loose token perms)
  • +Source maps published in production builds
  • +Suspicious or hallucinated package imports

Together, the two scanners give you full coverage: outside-in (live-domain) and inside-out (repo).

Vulnerability Disclosure Policy

Good-faith security research

We welcome responsible reports that help protect UNPWNED and its users. This policy defines the limited authorization, rules of engagement, and safe harbor available to good-faith security researchers. We aim to acknowledge reports within 48 hours and will keep reporters informed as we validate and remediate confirmed issues.

In scope

  • +https://unpwned.io and https://www.unpwned.io, including same-origin first-party API routes
  • +Authentication, session management, and account authorization tested only with accounts you control
  • +UNPWNED-side GitHub OAuth token handling, excluding GitHub systems and infrastructure
  • +Scan result and report access controls tested only with data you created
  • +UNPWNED database authorization and row-level access-control bypasses demonstrated with your own test data

Out of scope

  • -Customer domains, scan targets, public reports, or any asset not owned and controlled by UNPWNED
  • -demo.unpwned.io, other UNPWNED subdomains not expressly listed above, and third-party services or infrastructure
  • -Denial of service, resource exhaustion, destructive testing, malware, or persistence
  • -Social engineering, phishing, physical attacks, credential stuffing, password spraying, or brute force
  • -Spam, bulk or fake account creation, payment testing, and rate-limit or security-control evasion
  • -Automated or high-volume scanning unless UNPWNED gives prior written authorization

Rules of engagement

  • Use only accounts and data you own or have created for testing, and identify those test accounts in your report.
  • Use the minimum number of requests and the least data necessary to confirm the vulnerability. Stop after establishing a reproducible proof of concept.
  • If you encounter another person’s data, stop immediately. Do not copy, retain, alter, download, or disclose it, and notify us without delay.
  • Do not establish persistence, move laterally, exfiltrate data, modify or delete records, access secrets, interrupt service, or degrade another user’s experience.
  • Do not evade a suspension, IP block, rate limit, or other security control by changing accounts, identities, networks, tooling, or infrastructure.
  • Do not use a report or vulnerability to threaten, extort, demand payment, or seek commercial leverage.
  • Report privately and coordinate public disclosure with us. We normally ask for up to 90 days from acknowledgment to investigate and remediate, unless we agree otherwise or disclosure is legally required.

Conditional safe harbor

When research is conducted in good faith, remains within the scope above, follows every rule in this policy, and complies with applicable law, UNPWNED considers that research authorized by UNPWNED. We will not initiate civil action or ask law enforcement to investigate you for accidental, good-faith violations of this policy.

This authorization is limited to systems UNPWNED owns and controls. It cannot authorize testing of customer or third-party assets, bind any third party, provide immunity from applicable law, or protect bad-faith conduct. If you are unsure whether an action is permitted, email us and obtain written authorization before proceeding.

Abuse response and enforcement

Activity outside this policy is not authorized. Depending on intent, impact, repetition, and attempts to evade controls, UNPWNED may throttle or block access, revoke sessions and API credentials, suspend or terminate accounts without prior notice, preserve relevant security evidence under our Privacy Policy, notify affected infrastructure providers, and pursue civil remedies or refer suspected criminal activity to the appropriate authorities.

A person affected by an automated block may request human review at [email protected]. Repeated testing after a block or suspension, or returning through a new account or network to evade enforcement, is not treated as good-faith research.

What to include in your report

  • 1.Description of the vulnerability and its potential impact
  • 2.Steps to reproduce (or a proof-of-concept)
  • 3.The affected URL, endpoint, or component
  • 4.Your name or handle for acknowledgment (optional)

Email your findings to [email protected]. Please include a safe contact method and do not send secrets or personal data by email. We may credit researchers who report valid vulnerabilities and request acknowledgment. UNPWNED does not operate a bug bounty and does not promise payment unless a reward is agreed in writing before the report is submitted.

Acknowledgments

2026-03-16

Anonymous Researcher

Reported a privilege escalation vulnerability in profile creation and identified overly permissive database access policies. Both issues were patched within hours of disclosure. Thank you for helping make UNPWNED more secure.

Security.txt

UNPWNED publishes a machine-readable security.txt file at the standard location per RFC 9116. This helps security researchers and automated tools find our disclosure contact without guessing.

/.well-known/security.txt

What Neither Scanner Covers

No scanner result should be treated as a compliance certificate. UNPWNED scans for common security gaps from the outside (live-domain) and inside (your repo). It does not replace a manual code review of your authentication and access control logic.

Industry Context

Every major scanner ships with identical "as-is" disclaimers — Snyk does not warrant finding all vulnerabilities, GitHub provides Dependabot without warranty of any kind, and Checkmarx caps its total liability at $100. The difference is they bury these limits in pages of legalese. We put ours on the security page.

Out of scope for both scanners

These require manual review or specialised tooling. Even if you run both scanners, you should not assume the items below are covered.

  • -Application business logic flaws
  • -Static source code analysis (SAST) of your application code
  • -Authenticated routes that sit behind your login
  • -Internal SQL injection in queries we never see
  • -Memory safety and buffer-overflow issues
  • -Cryptographic implementation flaws
  • -Race conditions and concurrency bugs
  • -Third-party dependency vulnerabilities in code we cannot see (e.g. backend services not in the connected repo)

Threat Intelligence

Learn what attackers look for in production web apps and how to defend against common attack patterns.

Questions about our security practices?

Reach us at [email protected] and we'll get back to you within 24 hours.

Start Scanning Free

Compliance Disclosures

SOC 2: UNPWNED has not completed a formal SOC 2 Type II attestation. Our security controls are designed and operated in alignment with the SOC 2 Trust Services Criteria (Security, Availability, Confidentiality). This includes encryption at rest and in transit, role-based access controls, audit logging, incident response procedures, and regular security assessments.

GDPR: GDPR compliance is implemented through AES-256 encryption at rest, TLS 1.3 in transit, role-based access controls, right to deletion (account and data removal on request), data processing documentation, and minimal data collection practices. We do not sell or share personal data with third parties for marketing purposes.