A vulnerability report is one of the most sensitive documents a security team produces. It catalogues exactly where an organisation is exposed, ranks the findings by severity, and often names the assets, hostnames and CVEs an attacker would target first. The moment that report leaves your platform, it stops being your problem and becomes a delivery problem. How does an external auditor open it without a login? How do you stop a forwarded link from circulating forever? How does the recipient know the file they hold is the file you signed, byte for byte?
This article is about the delivery half of reporting, not the production half. If you want to understand how PMAP builds the deliverable itself across PDF, DOCX and HTML, that lives in a separate piece on async report generation. Here the focus is narrower and arguably harder. Once a report exists, how do you hand it to someone outside your tenant in a way that is convenient for them and defensible for you. PMAP answers that with cryptographically random share tokens, optional passwords, server-evaluated expiry, AES-256 PDF encryption for email, and SHA-256 signing backed by a QR verification page that needs no account. Every behaviour described below is grounded in how the platform actually works.
Why Emailing a PDF Is Not Secure Delivery
The default way most teams share a report is to attach the PDF to an email and hit send. It works, and that is exactly the problem. It works so smoothly that the failure modes never surface until they matter.
An email attachment has no expiry. The file sits in the recipient’s inbox indefinitely, gets forwarded to colleagues, lands in a shared drive, and resurfaces in a discovery request two years later. You have no record of who opened it, no way to pull it back, and no mechanism to confirm that the copy floating around matches what you originally produced. A recipient who wants to dispute a finding can quietly edit the PDF, and nothing in the email chain proves otherwise.
The external recipient persona makes this worse. Auditors, clients and remediation owners almost never have an account on your platform, and you do not want to provision one for a single download. So the report leaves the controlled environment of your tenant and travels as a loose file. The security boundary that governed it inside the platform evaporates at the inbox.
Secure delivery means the opposite of all of that. The link should be unguessable. It should be possible to set a deadline after which it stops working. It should optionally require a secret only the intended recipient holds. It should record access so you know the report was retrieved. And it should let the recipient prove the file is authentic without trusting your word for it. PMAP treats these as distinct, composable controls rather than a single blunt setting, which is what the rest of this article walks through.
Public Share Tokens Without a PMAP Account
The foundation of secure sharing in PMAP is the share token. When a report author wants to give an external party access to a completed report, they create a token from the share panel attached to that report. The platform generates a cryptographically random link that resolves to exactly one report file, and it returns the full share URL for the author to send.
The randomness here is not cosmetic. Each token is generated with Go’s crypto/rand, drawing 32 bytes and encoding them as a 64-character hexadecimal string. That yields roughly 256 bits of entropy. In practical terms, the keyspace is so large that brute-forcing a valid token at any realistic request rate is infeasible. There is no sequential identifier to increment, no predictable pattern to fuzz, and no way to enumerate one report from another. The token itself is the credential.
What the recipient sees on the other end is a no-auth branded landing page. They click the link, the page loads outside the authenticated application entirely, and they download the file. There is no signup, no password reset flow, no account provisioning, and no JWT to obtain. This matters for the external recipient experience because friction at the download step is where deliverables get stuck. An auditor who has to register an account to read a finding report will email you asking for the file as an attachment, and you are back where you started.
Because the token maps to a single report file, sharing is scoped at the artefact level rather than the account level. Giving someone a token does not give them a view into your reports list, your projects, or anyone else’s tenant. It gives them one finished document and nothing more. The share domain operates purely on the output artefact and is decoupled from the underlying scan and finding data.
Token Expiry and HTTP 410 Gone
A link that lives forever is a liability, so PMAP lets you attach a time-to-live to any token. At creation, the author can set expires_in_hours, and the token will stop working once that window closes. If no expiry is supplied, the token never expires, which is a deliberate choice rather than an oversight. Some deliverables genuinely need to stay available, and forcing an arbitrary deadline on every share would be its own kind of friction.
The important detail is where expiry is enforced. PMAP evaluates it server-side on every single public request, comparing the stored deadline against the current time. Expiry is not a client-side hint that a polite browser respects and a determined one ignores. When the deadline has passed, the public endpoint returns HTTP 410 Gone, and the public share page surfaces an expiry notice rather than a file. The 410 status is the correct semantic here. It tells the caller the resource existed and is now permanently unavailable, which is exactly what an expired share represents.
Setting an expiry on a token is the simplest way to bound your exposure. A report shared for a remediation review can be set to expire after the review window. An auditor deliverable can be timed to the engagement. The link becomes a perishable credential rather than a permanent one, and the cleanup happens automatically without anyone remembering to revoke it.
Password-Protected Downloads Done Right
Entropy in the link protects against guessing the URL. It does nothing about a URL that gets forwarded to the wrong person. For that, PMAP layers an optional password on top of the token.
At token creation, the author can supply a plaintext password. PMAP never keeps that plaintext. It hashes the password with bcrypt at the library default cost, stores only the hash, and the original value is never written to disk in cleartext and never returned in any API response. This follows the OWASP password storage guidance on using an adaptive, salted hash rather than a fast general-purpose digest. Bcrypt is deliberately slow and per-hash salted, which is what you want for a secret a human might choose and an attacker might try to guess.
The verification flow is where PMAP makes a careful engineering choice. Rather than checking the password inline on the download request, the public page calls a dedicated verify-password step first. The recipient’s browser posts the password to a verification endpoint, which validates the bcrypt hash and returns a simple JSON confirmation on success. Only after that confirmation does the page trigger the actual file download.
This split exists for a concrete reason. A file download is a streaming binary response, and HTTP download managers behave badly when a streaming endpoint returns an authentication error mid-stream. By validating the password as a clean, separate JSON exchange before any bytes start flowing, PMAP prevents a download manager from intercepting a 401 on the binary endpoint and mangling the experience. The recipient gets a clear password prompt, a clear success or failure, and then a clean download. The two concerns never collide.
A password and an expiry together give you a tightly bounded share. The link is unguessable, it stops working on a deadline, and even a leaked link is useless without the secret you communicated through a separate channel. That separation, link in one place and password in another, is the practical core of the OWASP access control guidance applied to file delivery.
AES-256 PDF Encryption for Email Delivery
Tokens cover the case where you want the recipient to pull the file. Sometimes you need to push it instead, by email, because that is how a particular client or auditor expects to receive deliverables. PMAP handles that without abandoning encryption.
When a report is delivered by email with a delivery password set, the PDF attachment is encrypted with AES-256 before it leaves the platform. PMAP uses the pdfcpu library to apply the encryption, so the file that lands in the recipient’s inbox cannot be opened without the password. The plaintext attachment never travels unprotected.
The password itself is included in the email body as a code block. That is a deliberate convenience for the recipient, who needs the password to open the file they just received. It also reflects an honest assessment of the threat model. Encrypting the attachment protects the file if the email is forwarded, archived in a shared mailbox, or sits on a mail server you do not control. It is not designed to defend against an attacker who has already fully compromised the recipient’s inbox, because at that point the same attacker reads the password too. Within the realistic threat of accidental forwarding and broad inbox exposure, AES-256 on the attachment is a meaningful control, and it is the right tool for email delivery specifically.
Email-based delivery and token-based sharing are not competing options. They serve different recipient preferences. A client who wants a portal-style download link gets a token. A client whose process is built around email attachments gets an encrypted PDF with the password inline. Both paths keep the file protected outside your platform.
SHA-256 Signing and QR Integrity Verification
Confidentiality is only half of trustworthy delivery. The other half is integrity. A recipient holding your report needs to be able to answer one question with certainty. Is this the exact file the security team produced, or has it been altered since.
PMAP answers that with SHA-256 signing. When an author signs a completed report, the platform computes a SHA-256 hash of the generated file and stores it in a dedicated signatures record alongside who signed it and when. SHA-256 is a cryptographic hash, so any change to the file, even a single byte, produces a completely different hash. The stored hash becomes the fingerprint of the authentic file.
What turns that hash into something a non-technical recipient can use is the QR code. When the report is signed, PMAP returns a base64-encoded QR code as a data URI. That QR code points at a public verification endpoint. A recipient can scan it, land on a verification page, and confirm the file integrity without holding a PMAP account. The verify endpoint takes the hash as a parameter and confirms a match, returning a clean success when the stored hash and the presented hash agree. No login, no tenant scope, no friction.
This is what makes signing useful as audit and compliance evidence rather than just an internal checkbox. A compliance officer can sign a regulatory report, hand the recipient a QR code, and the recipient can independently verify that the document they are filing is the document that was signed. If the file is later altered, the hash no longer matches, and the tampering is detectable by anyone with the QR code. The integrity claim does not rest on trusting the email, the channel, or your assertion. It rests on the mathematics of the hash, which is the entire point of using one. The signing and verification design follows the spirit of the OWASP cryptographic storage guidance on using strong, standard primitives for integrity rather than home-grown checks.
If the integrity record needs to feed a broader audit trail, that evidence chain belongs to a compliance-focused discussion rather than this one. Here the relevant fact is simply that every signed report carries a verifiable, account-free integrity proof.
Access Tracking and Instant Revocation
A share you cannot observe is a share you cannot govern. PMAP records access so that the author always knows whether and when a shared report was retrieved.
On every successful download through a share token, the platform increments an access counter and records the last-accessed timestamp. Those values are surfaced back to the authenticated user who manages the token, so the share panel shows not just that a link exists but how many times it has been used and when it was last opened. An author can tell at a glance whether the auditor has actually downloaded the report or whether the link is still sitting unopened.
The access recording is intentionally fire-and-forget. It never blocks the download. If the platform is under heavy concurrent load, the counter may lag briefly, but the recipient’s download never waits on a write to an access log. The design treats the file delivery as the priority and the bookkeeping as a non-blocking side effect, which keeps the recipient experience fast even when tracking is happening underneath.
Revocation is the other half of governance, and PMAP makes it immediate. When an author revokes a share token, the token is hard-deleted. The public link stops resolving at once. A recipient who tries to use a revoked link afterwards finds that it is no longer valid. There is no soft-delete grace period and no cached copy that keeps serving the file. If a link was sent to the wrong address, or an engagement ends early, or a deliverable needs to be pulled, revocation severs access in seconds rather than waiting for an expiry that might be days away.
Expiry and revocation cover the two ways a share should end. Expiry is the planned, automatic close at a known deadline. Revocation is the unplanned, manual kill switch. Together they mean no share has to live one moment longer than you intend.
Per-User Template and Report Sharing Inside the Platform
Not every share goes to an external party. Sometimes a colleague on your own team needs access to a report template you built, or to a report itself, and the right model there is a named grant rather than an anonymous public link.
PMAP supports this with per-user sharing. An authenticated user can grant a named colleague either view or edit access to a report template through an upsert-safe share table, and revoke it at any time. Because the share table is upsert-safe, re-sharing the same template with the same colleague updates the existing grant cleanly rather than creating duplicate rows. The grant is explicit, attributed, and reversible.
This internal sharing is a different mechanism from the public token for a good reason. A teammate already has an account, a session, and a place in your tenant’s access model. They do not need an anonymous link with its own password and expiry. They need a named permission tied to their identity, which is auditable in a way an anonymous token is not. PMAP keeps the two paths distinct. Public tokens for people outside the platform, named grants for people inside it. Each path fits its audience, and neither is bent to serve the other’s case.
Isolating Public Routes From the Authenticated Tree
The convenience of no-auth sharing raises an obvious architectural risk. If anonymous public endpoints sit anywhere near your authenticated API surface, you have created a place where a routing mistake could expose authenticated data to an unauthenticated caller. PMAP addresses this with deliberate route isolation.
The public share endpoints are registered as direct route handlers on the root router rather than mounted inside the authenticated subtree. The authenticated report management routes live under the JWT middleware group, where every request must carry a valid session token and pass tenant scope checks. The public share routes live outside that group entirely. No JWT middleware applies to them, because by design they must work for callers who have no credentials at all.
Registering the public routes directly, rather than mounting them, also avoids path shadowing. The authenticated reports tree and the public share tree share a URL prefix, and a careless mount could let one shadow the other and intercept requests meant for the wrong handler. Direct registration keeps the boundaries explicit, so the authenticated path stays authenticated and the public path stays narrowly scoped to token-based access.
There is a security-relevant consequence in how unknown tokens behave. A request for a token that does not exist returns a not-found response rather than a forbidden one. The distinction matters because a forbidden response confirms that a resource exists but is off limits, which leaks information an attacker can use. Returning not-found for an invalid token reveals nothing about whether any particular token is real. The same existence-hiding discipline that governs the authenticated reports list, which returns 404 rather than 403 to avoid leaking that a report exists, carries through to the public share surface.
Where the Security Boundary Sits
Honesty about the security model is part of trusting it. PMAP’s share design is deliberately layered, and it is worth being precise about what each layer does and does not cover.
The platform does not implement rate-limiting or an attempt counter at the service layer for share-token password guessing. That is an intentional boundary, not a gap left by accident. The token entropy already makes guessing the link itself infeasible, and password protection is an additional layer on top of an already unguessable URL. Defending the password-verification endpoint against high-volume automated guessing is expected to be handled by infrastructure-level controls, the same web application firewall, reverse proxy and rate-limiting layer that fronts the rest of the deployment. This mirrors the NIST SP 800-63B guidance on rate-limiting authentication attempts at the appropriate layer of the stack.
Knowing where the boundary sits lets you deploy the platform correctly. If you put PMAP behind the kind of infrastructure protection that any production deployment of an internet-facing service already needs, the share endpoints inherit that protection. The platform handles entropy, hashing, expiry, signing and isolation. The infrastructure handles volumetric abuse. Each layer does the job it is best placed to do, and the combination is what makes a no-auth share link safe to hand to an external party.
How PMAP Delivers Reports External Recipients Can Trust
Step back from the individual mechanisms and the shape of the approach becomes clear. Secure report sharing in PMAP is not a single setting you flip on. It is a set of composable controls that you combine to match the sensitivity of each deliverable and the workflow of each recipient.
For a routine internal review, a bare token with a short expiry may be enough. For a regulatory deliverable to an external auditor, you might create a password-protected token, set it to expire at the end of the engagement, sign the report with SHA-256, and hand over the QR code so the auditor can verify integrity independently. For a client whose process runs on email, you encrypt the PDF with AES-256 and let them pull the password from the message body. In every case the file leaves your platform protected, observable and revocable, and in every case the recipient needs no account to receive it.
That is the difference between sending a file and delivering a report. Sending a file ends your control at the inbox. Delivering a report means the link is unguessable, the deadline is enforced server-side, the password is hashed and never stored in cleartext, the file integrity is provable by anyone with the QR code, every access is recorded, and access can be cut off in seconds. The production side of reporting, covered in the companion piece on async report generation, gives you the deliverable. The sharing side gives you a way to put it in someone else’s hands without losing the security boundary that made the report worth trusting in the first place.
If you want to see how this fits the broader reporting story, including the analytics and KPI layer that feeds these documents, start with the pillar overview of vulnerability risk analytics and reporting. For a step-by-step walkthrough of creating a protected link, the guide on sharing reports via a public token with a password covers the exact flow. And to understand how an integrity-signed report becomes part of an audit evidence chain, the compliance and audit pillar picks up where this article leaves off.
Frequently Asked Questions
How secure is a PMAP share token against guessing?
Each share token is generated with crypto/rand, drawing 32 bytes encoded as a 64-character hexadecimal string, which gives roughly 256 bits of entropy. There is no sequential pattern and no way to enumerate one token from another. At any realistic request rate, brute-forcing a valid token is infeasible. The token itself functions as the access credential.
Do external recipients need a PMAP account to download a shared report?
No. The public share page loads entirely outside the authenticated application, with no JWT and no login. A recipient clicks the link, optionally enters a password if one was set, and downloads the file. The public routes are registered directly on the root router specifically so that callers without any credentials can use a valid token.
What happens when a share link expires or is revoked?
If a token has an expiry, PMAP evaluates it server-side on every request and returns HTTP 410 Gone once the deadline has passed, with an expiry notice shown on the public page. Revocation hard-deletes the token, so the public link stops resolving immediately and a recipient who tries a revoked link finds it is no longer valid. Expiry is the planned automatic close, and revocation is the immediate manual kill switch.
How does password protection on a share link work?
At token creation the author supplies a plaintext password, which PMAP hashes with bcrypt at the default cost and stores only as a hash. The plaintext is never stored or returned. When a recipient opens the link, the page calls a dedicated verify-password step first, which validates the bcrypt hash and returns a JSON confirmation, and only then triggers the download. This separation prevents download managers from mishandling an authentication error on the binary download endpoint.
How can a recipient verify a report has not been tampered with?
When an author signs a completed report, PMAP computes a SHA-256 hash of the file and returns a base64 QR code data URI pointing at a public verification endpoint. The recipient scans the QR code and confirms the hash matches, with no account required. Because SHA-256 changes completely if even one byte of the file changes, any tampering after signing is detectable by anyone holding the QR code.
Can I send an encrypted report by email instead of using a share link?
Yes. When a report is delivered by email with a delivery password set, the PDF attachment is encrypted with AES-256 using the pdfcpu library before it is sent, and the password is included in the email body so the recipient can open it. This protects the file against accidental forwarding and broad inbox exposure. Token-based sharing and encrypted email delivery serve different recipient preferences and can be used as the workflow requires.
Does PMAP rate-limit password guessing on share links?
PMAP does not implement a service-layer rate limit or attempt counter for share-token password guessing. This is a deliberate boundary. The token’s 256-bit entropy already makes the link itself unguessable, and password protection is an additional layer. Defending the verification endpoint against high-volume automated guessing is expected to be handled by infrastructure-level controls such as a web application firewall or reverse-proxy rate limiting that fronts the deployment.
