Your download page is a target, because anyone who can change it can change what users install. Protect the page like a release system: serve it over HTTPS, publish verification steps and hashes, sign artifacts, limit who can edit it, and watch for unexpected changes. Users should not have to guess which file is real.
Why the page matters
Attackers do not always need to break your signing. Replacing a link or a hash on the page can be enough if users trust the page alone. That is why a checksum on the same page as the file provides limited value, as we explain in checksum or signature.
Protect the page
- Serve everything over HTTPS, including the downloads and any redirect targets.
- Restrict who can edit the page and the files behind it. Require strong sign-in for those accounts.
- Keep download files in storage that only the release pipeline can write to.
- Log changes and alert on edits to download links or hashes.
- Watch for lookalike domains and ads that impersonate your page, and tell users your exact address.
Publish what users need to verify
- The publisher name they should see in the OS prompt.
- SHA-256 hashes, ideally also posted in release notes or another channel.
- Short, tested steps per platform: Windows signature check, Mac first-launch behaviour, Android certificate fingerprint. See SignTool steps and apksigner steps.
- The signing key fingerprint for package repositories, as in signed-by setup.
- A statement about what to expect on first launch. Microsoft notes that new releases may show SmartScreen prompts until reputation builds, so telling early users avoids confusion and pushes them to check the publisher name.
Be clear about what you ship
List every platform and format accurately. Do not imply support for a device or store you do not ship to. Users who hunt for a build you do not offer end up on third party mirrors, which are riskier than anything you publish.
Handle mirrors and third party listings
Search for your product name plus download. Report fake listings. Link to your official page from your documentation, social profiles and repositories, so there is a consistent set of places confirming the real address.
Keep it current
Remove old versions that have known flaws, or label them clearly. Update the page when keys or certificates change.
Review it quarterly
Put a recurring item on the calendar. Click every download link, verify each file against its hash and signature, and confirm the instructions still match what users will see. Check who has edit access, remove accounts that should not have it, and look at the change history for edits you did not expect. A page that was correct at launch drifts over time.
Quick check
Is HTTPS enough to trust a download page?
It protects the connection to the site. It does not protect against someone who can edit the site.
Where should I put the hash?
On the download page, and also in a second place such as release notes, so an attacker must change both.
Sources
Last reviewed: 19 October 2026.
