Security at Career1

Career1 holds resumes, interview recordings and assessments of real people, so this page sets out plainly what protects them. It lists only measures that are in place today, and section 9 lists the ones that are not, so that nobody has to guess.

1. Infrastructure

The application, its database and its cache run on servers operated by Contabo in France. Resumes, interview recordings, company logos and database backups are stored in Amazon S3 in Stockholm. Both are in the EU.
The credentials the application uses for Amazon S3 have no permission to delete or list stored files.
Resumes and recordings are never public: each is opened through a signed link that expires after a short time.
Card payments are taken on Stripe's hosted checkout. Card details never reach Career1.
Pages may not be framed by other sites, browsers are told not to guess content types, referrers are trimmed when you leave the site, and pages cannot ask for your location or for payment or USB devices.

2. Encryption

Every connection to Career1 is encrypted with TLS, using certificates from Let's Encrypt, and browsers are told to use only HTTPS for a year (HTTP Strict Transport Security).
Connections from Career1 to its providers, including Amazon S3 and OpenAI, use TLS, with the one exception listed in section 9.
Google Calendar access tokens are encrypted in the database. The application does not encrypt other stored data itself.

3. Passwords and sessions

Passwords are hashed with Argon2 and must be at least eight characters.
Sign-in sessions are held on the server, so they can be revoked. The session cookie is HttpOnly and SameSite=Lax, and it and every other sign-in cookie are marked Secure, so they are only ever sent over HTTPS.
Session, invitation, password-reset, email-confirmation and interview-link tokens are random values of about 256 bits, and only their SHA-256 hashes are stored, so a copy of the database would not contain a usable one.
Where one of those tokens is part of a page address, such as an interview, confirmation, password-reset, invitation, share or call link, it is replaced by a placeholder before our visit records, session-replay journeys or application logs store the address.
Inside a company workspace, roles run from hiring manager through recruiter and admin to owner, and the more sensitive actions need a higher role.

4. Administrator access

Career1's administration area is open only to an allow-list of email addresses, and every sign-in also needs a six-digit code sent to that address, which expires after ten minutes and allows five attempts.
Anyone else is answered with "not found", so the area does not reveal that it exists.
Every administrator sign-in is recorded.

5. Isolation between companies

Each company's jobs, applicants, interviews and reports are kept apart from every other company's at three levels in the code: the normal data-access layer is scoped to one company; a filter applied to every database query restricts it to the current company, even for a query written by hand; and a check before anything is saved refuses to write a row that belongs to another company. Code that must work across companies, such as background jobs and the administration area, has to say so explicitly.

6. Abuse controls

Rate limits on password sign-in, requests for administrator sign-in codes, password-reset requests, sign-ups, the free tools, the help assistant and session-replay uploads.
Sign-ups and practice interviews from Tor exit nodes are refused.
Heuristics that catch spam sign-ups.
Company sign-up is confirmed by email before an account exists, and the form never reveals whether an address is already registered.

7. Backups

A full copy of the database is taken every night and stored on Amazon S3, in the EU. See section 9 for what is not yet true of them.

8. Audit logging

Career1 records sign-ins, changes to an application's stage, resume downloads, views of interview recordings, changes to a profile's visibility and deletions of company workspaces. Administrators' access is recorded too: every time one views an interview, a recording, a session replay or a person's profile, and every administrative action, such as resetting an interview or a connection, closing a support conversation or testing storage. Access to candidates' data can be traced afterwards.

9. What we don't claim

Career1 has no SOC 2 report and no ISO 27001 certification.
No independent penetration test has been carried out.
Database backups are not encrypted by Career1 before they are uploaded, and old backups are not yet deleted on a schedule.
Apart from Google Calendar tokens, the application does not encrypt stored data itself.
The site does not yet send a Content Security Policy.
Our web server's access log records full page addresses, including the private token in a link such as an interview or password-reset link.
The lookup that turns a visitor's IP address into an approximate location, made to ip-api.com, travels over an unencrypted connection.
There is no self-service account deletion or data export; both are done by hand on request. Most data has no automatic deletion schedule yet (see the Privacy Policy).
There is no paid bug bounty.

10. Reporting a vulnerability

If you think you have found a security flaw in Career1, email hello@career1.ai with "Security" in the subject. Please include:

what you found, and where: the page, address or request involved;
the steps to reproduce it;
what you believe someone could do with it;
how we can reach you.

We will acknowledge your report, keep you told of progress, and let you know when it is fixed.

Our commitment to you

If you act in good faith and within the rules below, we will treat your research as authorised, we will not take or support legal action against you for it, and we will not report you to law enforcement. If someone else brings a claim against you over research that followed these rules, we will make it known that it was authorised.

Test only with accounts you own or have permission to use. If you come across anyone else's data, stop, do not keep or share it, and tell us.
Do not degrade the service: no denial of service, no high-volume automated scanning, no spam, and nothing that would interrupt a candidate's interview.
No social engineering of our staff or users, and no physical attacks.
Do not test the services we use, such as OpenAI, Stripe, Google, GitHub, Amazon Web Services or Contabo; report issues in those to them.
Give us a reasonable time to fix a flaw before you disclose it publicly, and agree the timing with us.

The same contact is published in machine-readable form at /.well-known/security.txt.

Security