PrivateBin can protect paste contents with client-side encryption, but encryption alone does not decide who may open the application or retrieve a paste. This guide explains practical ways to add authentication and access control, how to test the boundary between an authenticated instance and an individual paste link, and which controls should be reviewed each month or quarter.
Overview
There are two separate access questions in a PrivateBin deployment:
- Who can reach the PrivateBin service? This is usually controlled by a reverse proxy, identity-aware gateway, VPN, firewall, or HTTP authentication layer.
- Who can open a particular paste? This depends on the paste URL, any configured expiration or burn-after-reading behavior, and the controls surrounding the application. A user who possesses a valid paste link may be able to use it unless an additional authorization layer is enforced.
That distinction matters for security and compliance. Requiring employees to sign in before reaching the site can reduce exposure and support organizational access policies, but it does not automatically create per-paste permissions. Treat a paste URL as sensitive access information, especially when it contains the information needed by the browser to decrypt the paste. Do not assume that an SSO login makes a link safe to forward or that PrivateBin provides a complete audit trail of every reader.
The most maintainable design is usually to place PrivateBin behind a trusted access layer, restrict network exposure, use short-lived or one-time paste settings where appropriate, and document the limits of link-based sharing. For a broader deployment review, pair this work with the PrivateBin Security Hardening Checklist for Self-Hosted Deployments.
What to track
1. The authentication boundary
Record exactly where authentication occurs. Common patterns include:
| Pattern | Useful for | Important limitation |
|---|---|---|
| Reverse-proxy HTTP authentication | Small internal teams and controlled administrative access | Credential management, logout behavior, and user lifecycle may be basic unless integrated with a directory |
| SSO or identity-aware gateway | Organizations that already manage users, groups, MFA, and sign-in policies centrally | The gateway authenticates access to the service; it does not automatically create per-paste authorization |
| VPN or private network access | Internal-only deployments and infrastructure teams | Anyone with network access may still reach the application unless application authentication is also required |
| Anonymous links | External sharing where recipients cannot be provisioned in an identity system | The link functions as a bearer capability; forwarding, browser history, referrer leakage, and chat retention become relevant risks |
Track the selected pattern, the systems it depends on, and the people responsible for reviewing it. For SSO, record the identity provider, protected groups, MFA expectations, session duration, logout method, and behavior when an account is disabled. For a reverse proxy, record which upstream is protected, which headers are forwarded, and whether direct access to the application origin is blocked.
2. Origin exposure and proxy behavior
Verify that users cannot bypass the authentication layer by connecting directly to the PrivateBin server, alternate hostname, exposed port, staging endpoint, or default load-balancer address. DNS records, firewall rules, security groups, and container or orchestration ingress settings should all support the same access decision.
Also check that the proxy preserves the request scheme and host information correctly, serves HTTPS consistently, and does not accidentally cache authenticated pages or paste responses. Authentication headers should be accepted only from the trusted proxy path. Do not let an internet client set a header that the application interprets as proof of identity.
3. Paste-level controls
For each use case, document whether the paste should be public to authenticated users, limited to a small group, protected by a separately communicated password, set to expire, or destroyed after reading. Choose the narrowest practical lifetime. A paste containing a password, token, personal data, or production log should not remain available indefinitely simply because the service is behind SSO.
Keep an inventory of enabled paste features that affect exposure, including file uploads, discussions, comments, previews, and metadata. Review upload limits and scanning expectations separately using the PrivateBin File Upload Security Checklist.
4. Logging and evidence
Track which component records sign-ins, failed authentication, administrative changes, proxy denials, and application errors. A reverse proxy may show that a user reached a URL without proving that the person successfully decrypted or read a paste. If audit evidence is required, define this limitation explicitly rather than presenting access logs as proof of content access. The audit evidence checklist can help organize related records.
Cadence and checkpoints
Before go-live
- Place the service behind the selected reverse proxy, gateway, or private network boundary.
- Allow only the required upstream path and block direct origin access.
- Test an unauthenticated request, an authenticated request, a disabled account, and a user outside the permitted group.
- Confirm that HTTPS, redirects, cookies, and session expiration behave as intended.
- Create test pastes with different expiration and burn-after-reading settings. Verify what happens when the URL is opened in a second browser or by a user who is authenticated but not an intended recipient.
- Confirm that logs contain enough operational evidence without recording paste contents, encryption keys, passwords, or sensitive URL fragments unnecessarily.
Monthly review
Check for unauthorized origin exposure, stale DNS records, unexpected proxy routes, failed authentication spikes, and changes to the protected group. Review a small sample of paste lifetimes and confirm that teams are using expiration and one-time access appropriately. Verify that disabled or departed users no longer pass the access gateway.
Quarterly review
Re-test the complete access path after proxy, identity-provider, browser, container, or PrivateBin configuration changes. Review administrator membership, service accounts, firewall rules, TLS settings, backup handling, and retention decisions. Ask whether the original sharing model still fits: an internal link-sharing service may become unsuitable when external recipients, regulated data, or stronger per-recipient authorization requirements are introduced.
How to interpret changes
A successful SSO redirect proves only that the gateway recognized a user under its current policy. It does not prove that the user should access every paste. If all authenticated users can open every valid link, describe the deployment as instance-level authentication with link-based paste access, not as fine-grained authorization.
A rise in denied requests may indicate effective enforcement, but it can also result from a broken callback URL, an expired session, a misconfigured trusted-header rule, or a group-mapping error. Compare proxy logs with identity-provider events and application health before changing permissions. Conversely, a lack of denied requests is not evidence that the control is working; it may mean that the test did not include an unauthorized user or a direct-origin attempt.
If a paste link leaks, assume that authentication alone may not be sufficient unless the link is also bound to the intended identity by a tested control. Revoke or destroy the paste where possible, rotate any embedded credentials, preserve relevant operational evidence, and notify the responsible owner. Use the PrivateBin Incident Response Runbook for a structured response.
When requirements call for per-user authorization, centralized revocation, detailed reader audit trails, or formal approval workflows, do not stretch a simple paste service beyond its design. Consider an authenticated portal, managed secret-sharing system, or document platform that natively supports those controls. PrivateBin may still be useful for narrowly scoped, short-lived sharing, but the risk decision should be documented.
When to revisit
Revisit this article and your deployment checklist monthly for basic exposure checks and quarterly for a full access review. Review immediately after changing the identity provider, reverse proxy, DNS, firewall, TLS termination, session policy, container image, upload settings, or PrivateBin configuration. Also trigger a review when onboarding a new department, opening access to external recipients, handling a new category of personal or regulated data, or responding to a leaked link.
End each review with three concrete records: the access model currently in use, the tests performed and their results, and the owner plus deadline for unresolved findings. A practical next step is to create two test accounts—one authorized and one unauthorized—then verify the following in a controlled environment:
- The unauthorized account cannot reach the service or is rejected before the application loads.
- The authorized account can use the service without unexpected redirect or session failures.
- Direct-origin and alternate-hostname requests are blocked.
- A paste link behaves according to its documented sharing model, including after expiration, deletion, or burn-after-reading.
- Logs support troubleshooting without exposing paste contents or secrets.
Record the date and repeat these tests after every material access-control change. This turns PrivateBin authentication from a one-time configuration task into a manageable cloud security practice.
