Security & trust

Our approach

Verif_Hire is built by recruiters, for recruiters. Candidate data is sensitive, and the less we handle, the less there is to leak. This page describes what we do — and what we don't do — to keep that data safe.

Architecture summary

Client-side first

The Verif_Hire Chrome extension runs all resume parsing, form handling, and email-reputation checks locally in your browser. Resume PDFs and Word documents are never uploaded anywhere — they're parsed in-memory using pdf.js and mammoth.js and discarded when the popup closes.

Stateless API proxy

For signals that require an external lookup, the extension calls a Cloudflare Worker endpoint that proxies the request to an upstream provider and returns only the minimum fields needed. The Worker does not write the request payload to any database, log, or persistent store.

License server

Separately, we maintain a small license-management store (Cloudflare KV) that holds your license key, subscription status, and device identifier. That store contains no candidate data. It exists only to activate Pro plans and enforce anti-abuse rules on the free install.

Infrastructure

• Hosting: Marketing site on Netlify (HTTPS, HSTS preload). API on Cloudflare Workers (Anycast, DDoS-protected, TLS-terminated at the edge).
• Data stores: Cloudflare KV for license records only. No relational database. No candidate database.
• Payments: Processed exclusively by Stripe. We never see, handle, or store card numbers, bank details, or other payment instrument data.
• Email: Transactional license-key emails are sent via Resend on a domain we own (verif-hire.com) with SPF, DKIM, and DMARC configured.
• Secrets: All third-party API keys are stored as encrypted Worker secrets; they are never bundled into the extension or exposed client-side.

Transport & cryptography

• All endpoints are HTTPS-only with TLS 1.2 or higher.
• HSTS with includeSubDomains; preload is enforced on verif-hire.com.
• Security headers include X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and a locked-down Permissions-Policy that disables camera, microphone, geolocation, and FLoC cohorts.

Access controls

Production infrastructure is administered by the founder under two-factor-authenticated accounts on Cloudflare, Stripe, Netlify, and Resend. Deploy credentials rotate when team composition changes. There is no shared login.

Dependencies

The extension bundles two third-party libraries for resume parsing: pdf.js (Mozilla) and mammoth.js. Both run entirely in-browser. We pin versions, review changelogs on upgrade, and remove dependencies that add unnecessary network calls.

Chrome extension permissions

Verif_Hire requests the minimum set of permissions required:

• storage — to remember your license key and verification usage locally.
• activeTab — so the popup can pre-fill from the candidate page you're looking at, only when you click the toolbar icon.

We do not request <all_urls>, tabs, cookies, or any host permissions beyond what's needed for a single active tab. The full permission rationale is published on our Privacy page.

Vulnerability disclosure

If you believe you've found a security issue in Verif_Hire, please email security@verif-hire.com (or admin@verif-hire.com) with a description of the issue and reproduction steps. We'll acknowledge within two business days.

Please practice good-faith testing: don't exfiltrate data belonging to other users, don't disrupt service, and give us a reasonable window to fix the issue before public disclosure.

Compliance posture

Because Verif_Hire does not store candidate data, most data-subject rights under GDPR, CCPA/CPRA, and similar regimes are effectively satisfied by design. For the narrow set of data we do hold (license records, billing metadata), see our Privacy Policy for your rights and how to exercise them. Hiring teams using Verif_Hire remain the controller of any candidate data they process; see our Compliance Guide for how to use the tool responsibly.

Changes to this page

We revise this page when our architecture changes in a way that affects data handling. The "last reviewed" date at the top reflects the most recent review, even if no substantive change was needed.