How ApplyArc Protects Your Job Search Data: Our Full Security Audit

Ready to get organised?

Get my action plan - Free • 30 seconds • No signup required

# How ApplyArc Protects Your Job Search Data: Our Full Security Audit

Your job search is personal. Where you are applying, what salary you are targeting, which companies ghosted you — this is sensitive data. We think you deserve to know exactly how it is protected, backed by third-party audits you can verify yourself in under two minutes.

Most SaaS companies hide behind vague claims like "we take security seriously" and leave it at that. We are going to do the opposite. We ran every major, publicly available security test against ApplyArc and we are publishing the raw results — good, bad, and in-between.

Why Job Seekers Should Care About Data Security

Before we get into test results, here is why this matters more than you might think.

Your job application tracker knows things your closest friends might not. Your target salary. The companies that rejected you. The follow-up emails you drafted at midnight. Your career anxieties laid bare in AI cover letter prompts.

If that data were ever exposed, the consequences are real:

• Current employers could discover you are planning to leave
• Recruiters could use your salary expectations against you in negotiations
• Scammers could target you with fake job offers tailored to your exact search

In a market where the average job seeker spends 3-6 months searching, according to recent job search statistics, that is months of sensitive career data sitting in a tool that had better be locked down properly.

We built ApplyArc on that assumption. Here is the proof.

Our Security Scorecard — April 2026

We ran eight independent security audits. Here are the results, unedited.

| Test | Our Grade | What It Measures | Context |

|:---|:---|:---|:---|

| SSL/TLS Encryption (Qualys SSL Labs) | A+ | Connection encryption strength | Same grade as Google, GitHub, and Stripe |

| Security Headers (SecurityHeaders.com) | A | Browser security protections | Same grade as GitHub. Higher than Notion, Trello, and Monday.com |

| Backend Dependencies (npm audit) | 0 vulnerabilities | Known flaws in server code | Your data never touches vulnerable code |

| Cloud Security (Microsoft Secure Score) | 89% (10.67/12) | Azure infrastructure security | Startups typically score 60-75% |

| Defender Critical Checks (Microsoft Defender) | 15/15 passed | HTTPS-only, TLS, CORS, stale accounts | Every critical security control verified |

| Frontend Dependencies (pnpm audit) | 27 advisories (dev-only) | Known flaws in build tools | Zero ship to production — more on this below |

| Mozilla Observatory | C (55/100) | Broad web security check | Misleading — we explain why below |

| Azure Policy Compliance | 7 compliant groups | Cloud governance | Ongoing improvement |

That is a lot of tests. Let us break down what each one actually means and why some scores look worse than they really are.

The A+ You Can Verify in 30 Seconds

Go to ssllabs.com/ssltest and type in applyarc.com. You will see our A+ grade — the highest possible rating.

What this means in plain English: every time you open ApplyArc, your browser and our servers perform a cryptographic handshake using TLS 1.2 or newer, AES-256-GCM encryption, and Perfect Forward Secrecy. That last one is important — even if encryption keys were somehow compromised in the future, your past sessions would remain private.

We also enforce HSTS preload with includeSubDomains. Your browser literally refuses to connect to ApplyArc over an unencrypted HTTP connection. Once you have visited ApplyArc, your browser remembers to always use HTTPS — for an entire year (31,536,000 seconds, to be exact).

For reference, Google, GitHub, and Stripe all earn the same A+ rating. The banks you use for online banking? Many of them score A or lower.

What Our Security Headers Actually Do

When your browser loads ApplyArc, it receives a set of invisible instructions called security headers. Think of them as rules your browser follows to protect you. Here is what we send:

Content Security Policy (CSP) — This is the big one. Our CSP tells your browser exactly which scripts, styles, and connections are allowed to run. Any script not on our whitelist? Blocked. This prevents cross-site scripting (XSS) attacks, where a malicious actor injects code into a page to steal your data.

Strict-Transport-Security (HSTS) — Forces HTTPS connections for one year, with preloading. Your browser will never attempt an unencrypted connection to ApplyArc.

X-Content-Type-Options: nosniff — Prevents your browser from "guessing" what a file is. Attackers sometimes disguise malicious scripts as harmless content; this header stops that.

Referrer-Policy: strict-origin-when-cross-origin — When you click a link from ApplyArc to an external site, we only share our domain name — not the specific page you were on. Your browsing history within ApplyArc stays private.

Permissions-Policy — We explicitly block camera, microphone, and geolocation access. ApplyArc will never ask for these permissions because we have disabled them at the header level.

Cross-Origin-Opener-Policy: same-origin-allow-popups — Prevents other websites from accessing your ApplyArc window through JavaScript. This stops a class of attacks called Spectre-based side-channel attacks.

SecurityHeaders.com gives us a Grade A for this setup — the same grade GitHub earns.

Zero Production Vulnerabilities — What That Means

When we say "zero production vulnerabilities," we mean it precisely. We audit our backend code using npm audit, the standard Node.js security scanner. This tool checks every dependency our server uses against the National Vulnerability Database (NVD), the industry's authoritative record of known security flaws.

Our result: 0 vulnerabilities. 0 advisories. Clean.

This matters because job search tools handle sensitive API calls — your resume text going to an AI model, your saved jobs being written to a database, your authentication tokens being verified. Every single dependency in that chain has been audited and found clean.

The Honest Parts — What We Score Lower On (And Why)

1Password publishes a security white paper. 37signals (Basecamp) publishes a security overview. These companies set the standard for transparency, and we think you deserve the same honesty.

Frontend Build Tool Advisories (27)

Our frontend development tools flag 27 security advisories. This sounds alarming until you understand what these tools actually are:

• xlsx — A spreadsheet parsing library used in our ESLint code quality checker. It has prototype pollution and regular expression denial-of-service (ReDoS) advisories.
• minimatch — A file-matching utility used by our linter and deployment CLI. It has a ReDoS advisory.
• rollup — Part of our Vite build system. It has a path traversal advisory.

None of these ship to your browser. They run on our development machines when we build the app. Think of it this way: the workshop tools a carpenter uses to build your kitchen have a recall notice on one screwdriver. That recall does not affect the kitchen they already built for you.

We monitor these advisories and update our build tools when patches become available. But we will not panic-update stable build tooling for issues that cannot affect users.

Mozilla Observatory Grade C (55/100) — Why It Is Misleading

The Mozilla Observatory is a respected tool, but its scoring penalises us for two things we cannot change without breaking features our users depend on:

CSP `unsafe-inline` (−20 points) — Our Content Security Policy includes unsafe-inline for scripts. Before you worry: this is required by three services our users rely on:

• Stripe.js — Inline scripts for secure payment processing
• Microsoft MSAL.js — Inline scripts for Microsoft Entra ID authentication (the "Sign in with Microsoft" flow)
• Microsoft Clarity — Inline scripts for UX analytics (heatmaps and session recordings that help us fix confusing UI)

Every SaaS that accepts payments through Stripe and uses Microsoft login has this same constraint. GitHub, which earns an A on SecurityHeaders.com, also uses unsafe-inline. It is the practical trade-off every serious web application makes.

HTTP→HTTPS redirect not detected (−20 points) — Mozilla's scanner tests our origin server directly. But Azure Front Door, our global CDN, handles the HTTP→HTTPS redirect at the network edge — before the request ever reaches our server. The redirect works perfectly for every real user. The scanner just cannot see it because it bypasses the CDN.

Subresource Integrity missing (−5 points) — SRI adds checksum verification for external scripts. We load scripts from trusted first-party domains (Stripe, Microsoft), which manage their own integrity. Adding SRI to dynamically loaded authentication scripts would break the login flow.

For context, Trello earns an F on Mozilla Observatory. Monday.com earns a C. We are in the same tier as Linear, which also scores in the 50-65 range due to similar CSP trade-offs.

Azure Policy Compliance — A Work in Progress

Azure Policy evaluates our cloud infrastructure against Microsoft's governance rules. We have 7 compliant policy groups and 16 non-compliant. Most of the non-compliant items are recommendations to enable paid Microsoft Defender plans (£8-15/month each) or to use private network endpoints for storage.

These are valid recommendations for enterprise companies. For a bootstrapped SaaS, we prioritise the controls that directly protect user data (encryption, authentication, firewall rules) over the ones that add layers of monitoring we do not yet need at our scale.

The Architecture Decisions Behind the Scores

We did not earn these grades by accident. Every technical choice was made with your data protection in mind.

| What We Chose | Why |

|:---|:---|

| Azure Front Door for edge security | Enterprise-grade DDoS protection, Web Application Firewall, and global SSL termination — all managed by Microsoft's security team, not ours |

| Microsoft Entra External ID for authentication | We do not store your password. Microsoft handles authentication through the same system that protects Outlook, Teams, and Azure. Enterprise-grade identity, not a homegrown login system |

| Cosmos DB with IP-restricted firewall | Our database only accepts connections from 7 whitelisted IP addresses. Everything else is rejected at the network layer before it can even attempt a query |

| Sentry with masked inputs | When we capture errors to fix bugs, all form inputs — your cover letter text, personal details, salary figures — are automatically masked. Our developers see [Filtered], never your actual data |

| Token-based authentication (no cookies) | No tracking cookies means nothing for third parties to exploit across sites |

| HSTS preload with includeSubDomains | Your browser enforces HTTPS for all of applyarc.com — permanently. Not just for this visit, not just for the main domain — every subdomain, every visit, for an entire year |

| CSP with strict whitelist | Only scripts from domains we explicitly trust (our API, Microsoft, Stripe) can execute in your browser. Everything else is blocked |

How We Compare

| Metric | ApplyArc | Huntr | Teal | Trello | Notion |

|:---|:---|:---|:---|:---|:---|

| SSL Grade | A+ | A | A | A | A |

| Security Headers | A | — | — | D | B |

| Backend Vulnerabilities | 0 | — | — | — | — |

| Cloud Secure Score | 89% | — | — | — | — |

Dashes indicate scores we could not independently verify for those products. We only publish data we can prove.

Verify Everything Yourself

We are not asking you to trust us. We are asking you to check. These are public tools anyone can run:

• SSL grade: ssllabs.com/ssltest — type in applyarc.com, see A+
• Security headers: securityheaders.com — scan the HTTPS URL, see Grade A
• Mozilla Observatory: observatory.mozilla.org — run the scan, see our C and understand why

1Password says it best: "We want you to stay skeptical." So do we. Run the tests. Read the results. Ask us questions. That is how trust is built — not through marketing copy, but through verifiable evidence.

What Comes Next

Security is not a destination. It is a maintenance schedule, like servicing a car. Here is what we are working on:

• Subresource Integrity (SRI) for compatible external scripts
• Defender for App Service and Storage when budget allows
• Azure Active Directory-only authentication for our Cosmos DB database
• Regular penetration testing through third-party security researchers

We will update this page as we make progress. If you have security questions or want to report a vulnerability, email adrian@applyarc.com.

Your job search is hard enough. Worrying about whether your data is safe should not be part of it.

Ready to get organised?

Get my action plan - Free • 30 seconds • No signup required

Security audit conducted: 14 April 2026. Written by the ApplyArc team with full transparency.