Security

Last full pass: July 27, 2026

AutoApply holds your resume, your contact details, and the accounts you use to apply for jobs. That is worth taking seriously, so the code has been through two dedicated security passes. This page says what they covered, what came out of them, and how the product is built to limit the damage when something does go wrong.

What it deliberately does not do is publish a map of the app's soft spots. No specific weaknesses, no versions, no explanation of how a particular fix works. None of that helps you decide whether to trust the app, and all of it helps someone who is looking for a way in.

How it was reviewed

Two passes, both run in house with heavy AI assistance. Neither is a third party certification and this page is not an audit report. I would rather tell you exactly what it was than dress it up.

The first pass, in July, read the whole codebase, roughly 40,000 lines, starting from a map of its trust boundaries. It ran as sixteen parallel review lanes, one per security surface. Every finding was then re-checked adversarially by a second model whose only job was to disprove it. Three findings did not survive that check and were thrown out, and several severities were marked down. Guessing is cheap and wrong findings waste the time that should go to real ones.

The second pass, twelve days later, worked through an earlier review of the desktop app and then audited the three surfaces that review never saw: the Python backend, the server behind accounts and billing, and the build pipeline that produces the installer you download.

Fixes were not taken on trust. The second pass alone added 219 new tests. The packaged installer was built and launched and checked for console and content policy errors, the hardening flags were read back off the built binary rather than assumed from the config, and a live attack matrix was fired at the packaged app's own backend to confirm it rejected what it was supposed to reject.

What was in scope

• the server that handles sign in, payments, and AI metering;
• the desktop app's Python backend;
• the Electron shell the app runs inside;
• the app's user interface;
• the build and release pipeline.

The browser extension shipped after both passes and is not covered by them.

What came back clean

This is the part most people skip, and it is the part that actually matters, because these are the places where a job application tool would hurt you most if it were sloppy.

• Sign in. Token verification was correct, including the checks that are most often the ones people get wrong.
• Payments. The Stripe webhook verifies the signature before trusting anything, and what you bought is resolved from the real record on Stripe's side, never from something the app claims.
• Other people's data. Every server route that returns data scopes it to the account that asked. The review found no way to read someone else's records.
• Databases. No SQL injection anywhere, on the server or locally. Every query is parameterized.
• The AI proxy. It enforces a model allowlist and a token cap before anything goes upstream, and there was no way to point it somewhere else or pull the upstream key out of it.
• The interface. No raw HTML rendering, no eval, no secrets baked into the app.

What needed fixing

Plenty. Described by category, which is as specific as this page is going to get:

• secret handling, on the operations side rather than in the shipped product;
• how the desktop app handled file paths it was handed;
• usage metering, where the billing meter was not counting everything it should have;
• automation safety rules that were weaker in the code than the documentation claimed;
• installer and auto update integrity;
• handling of anything that arrives from outside, meaning job listings, emails, and the board addresses the app fetches on your behalf;
• a couple of places where data sitting on disk was less protected than it looked.

Everything on that list that was a code problem was fixed in code, with tests, in the same pass that found it.

Not all of it is closed. A few items are deliberate tradeoffs, written down as accepted risks with the reasoning attached rather than quietly ignored, and a few are operational follow ups. I am not going to list the open ones in public, and I hope that reads as the obvious call rather than a dodge.

One thing worth admitting

A change made during the hardening pass broke the packaged app completely. It came up as a blank white screen, every time. Static analysis said it was fine. The test suite said it was fine. The only thing that caught it was building the real installer and launching it.

That is the honest shape of this work. Tests are necessary and they are not sufficient, and a security change that bricks the app is not a security win.

How the product limits the damage

• Your data is local. Your resume, profile, applications, and job data live on your machine, not on a server. That is the architecture, not a setting you can forget to turn on. The flip side is real: the safety of that data rests on your computer's own protections, so a strong account password and full disk encryption matter here.
• The app never submits for you. A person clicks the final submit button, always. That rule was one of the things the review pushed hardest on, and the guard behind it was made stricter as a result.
• Installers are signed. Windows builds are code signed, and the signed build fails loudly if the signature did not take, so an unsigned installer never reaches the publish step.
• The app's local interface is authenticated. A website you happen to have open in another tab cannot reach it. Software already running under your own user account is a different matter. At that point it can read your files directly, and no app-level check changes that.
• Credentials stay in the operating system. Passwords live in the OS credential manager, and the session cookies for job boards you are signed into are encrypted at rest.
• Secret scanning at commit time. The repository carries a secret-scanning hook that blocks credentials at commit time.

Found something?

Email [email protected] and put security in the subject line. I read every email, and I would much rather hear it from you than not hear it at all. Please do not test against the live service or anyone else's account while you are looking into it.