Case study · Security engineering
Sharing my CV without publishing my phone number.
Blaze Link is the site you are on. It keeps my work public and my private details behind an access flow that I approve, that expires, and that I can revoke at any time.
The problem
At networking events I want to share my CV and contact details quickly. Putting them on a public page means anyone, including scrapers and scammers, has them for good.
So the public site shows my work, and the private details are released one person at a time, for a limited time, with a record of what happened.
How it works
- 01
Request
A visitor sends their name, email and reason. The form includes a hidden honeypot field for simple bots.
- 02
Review
I see the request in a private owner area that needs an email sign-in link, an authenticator code and an approved device.
- 03
Approve
I choose how long the link lasts and how many views it allows, and the link is emailed to the requester.
- 04
Access
They open a private page with my contact details and CV download, until it expires or I revoke it.
Architecture
Simplified. Secrets, internal names and private-area details are deliberately left out.
Security decisions
Only token hashes are stored
The database never holds a usable access link, so a copy of the table is not a copy of the access.
The token stays out of server logs
It travels in the URL fragment, which browsers do not send to servers, and the page removes it from the address bar once it has been read.
Every link has limits
An expiry time, an optional view limit, and revocation that takes effect straight away.
Owner access has layers
Email sign-in, TOTP MFA with a backup factor, a server-side owner check and trusted-device approval.
No secrets in the browser
Server keys live only in Edge Functions, and database tables use Row Level Security.
Analytics without tracking people
Page views, device type, referring site and a random session hash. The site's own analytics are designed not to store raw IP addresses.
Trade-offs
Revocation cannot recall a download.
Once someone saves the PDF it is outside my control. The access page says so plainly instead of overpromising.
Strong device rules can lock me out.
Trusted-device approval stops a stolen sign-in, but makes travel harder. Recovery is a separate, deliberately manual process outside the website, so a device can never approve itself.
"Sent" is not "delivered".
The system only knows the mail server accepted the email, so it says exactly that.
Validation
I test the deployed site within an authorised scope, covering its access controls, authentication boundaries and token handling, and use what I learn to keep hardening it. Security work here is ongoing rather than finished.
See it from the other side.
Request my CV and you will go through exactly this flow.