Job Search Data Privacy: ApplyArc Security Audit

Ready to get organised?

Get my action plan - Free, no signup required

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. For the wider picture of what ApplyArc is, how it is priced, and what it includes, see our verified ApplyArc facts.

What the ICO Found in AI Recruitment Tools

Candidate-side job-search tools and employer-side recruitment tools are not the same thing. A tracker helps you manage your own search. An employer's recruitment system may source, screen, summarise, rank, or filter candidates.

The UK Information Commissioner's Office audited developers and providers of AI-powered sourcing, screening, and selection tools in 2024. The ICO's audit overview says the work examined compliance with UK data protection law.

The ICO's published findings report almost 300 recommendations. The regulator found examples of:

• filtering that could exclude candidates using protected characteristics
• gender and ethnicity being inferred from a candidate's name
• more personal information being collected than necessary
• information being kept indefinitely to build candidate databases
• candidates receiving unclear information about how their data was used

Those findings do not prove every AI recruitment or job-search tool behaves that way. They establish the questions a job seeker should ask.

Before You Paste a CV Into Any AI Tool

1. Who controls the data? Is the product working for you, an employer, or both?

2. What is sent to AI? Look for whether the full document, selected text, or bounded excerpts leave the browser.

3. What is stored? Check the privacy notice for document, prompt, output, profile, and event retention.

4. Can you export and delete it? Find the controls before uploading, not after.

5. Is the result advisory or decisive? A score or ranking should not be presented as a guaranteed hiring outcome.

6. Does the tool infer sensitive traits? Be wary of systems claiming to infer personality, ethnicity, health, emotion, or protected characteristics from indirect data.

7. Who else receives it? Check subprocessors, employer access, advertising use, and model-training terms.

ApplyArc is a candidate-side workspace. It does not rank candidates for employers, send applications, or make hiring decisions. The sections below explain the controls ApplyArc actually uses and their limits.

Our Security Scorecard. April 2026

We ran eight security checks. These are dated snapshots, not a promise that software can never have a vulnerability.

| 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 known advisories | Published dependency advisories at scan time | A dependency scan, not a proof that application code is bug-free |

| Cloud Security (Microsoft Secure Score) | 89% (10.67/12) | Azure configuration on 14 April 2026 | A point-in-time configuration assessment |

| 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 use encrypted transport before any sensitive data moves across the connection. We do not ask users to paste CVs, salary notes, or interview prep into an unencrypted page.

We also send HSTS with includeSubDomains. After a supporting browser receives that header, it remembers to use HTTPS for ApplyArc for one year. ApplyArc is not currently on the browser preload list, so we do not claim protection before a browser has received the header.

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): Tells supporting browsers to keep using HTTPS for one year after receiving the header. ApplyArc is not currently on the browser preload list.

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.

What a Clean Dependency Audit Means

We audit backend dependencies using npm audit, the standard Node.js dependency scanner. It checks installed package versions against published security advisories.

On 14 April 2026, that scan reported 0 known advisories in the backend dependency tree.

That result is useful, but limited: it is a point-in-time dependency check. It does not prove that our own code has no defects, and new advisories can appear after a scan.

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 add further network hardening 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 | 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. Microsoft-managed identity, not a homegrown login system |

| Cosmos DB with private network access | Production database access stays on private Azure networking, and the application authenticates with managed identity rather than an embedded database key |

| Sentry with masked inputs and no network bodies | Browser replay masks form inputs and does not capture ApplyArc API request or response bodies. Error reports still contain technical metadata needed to diagnose a fault |

| Token-based authentication + consent controls | Authentication uses tokens. Optional Microsoft Clarity analytics cookies are enabled only after consent |

| HSTS with includeSubDomains | After receiving the header, supporting browsers remember to use HTTPS for ApplyArc and its subdomains for one year. The domain is not currently preloaded |

| 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 |

| Known backend dependency advisories (14 Apr scan) | 0 |, |, |, |, |

| Cloud Secure Score (14 Apr snapshot) | 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, no signup required

Security audit conducted: 14 April 2026. ICO recruitment-tool section reviewed 23 July 2026. Written by Adrian George with linked primary sources.