Security, trust, and compliance

PrintBridge binds its REST API to 127.0.0.1 (localhost) only. It never binds to 0.0.0.0 or any network-facing interface. A remote attacker — on your LAN, the internet, or any other machine — cannot reach the PrintBridge API.

The only exposure is local: any process with local code execution on the same machine could make HTTP requests to localhost. All endpoints except GET /status require a valid API key, which a random local process does not have.

The key is generated with Node.js's crypto.randomBytes(32) — 32 bytes (256 bits) of OS-level cryptographic randomness. This is the same entropy class as AES-256 keys. It cannot be brute-forced.

• Generated on first launch — no default or shared key
• Stored only on the local machine in %APPDATA%\PrintBridge\
• Never transmitted to PrintBridge servers or any third party
• Rotatable at any time from the app UI

Browsers attach an Origin header to cross-origin requests. When at least one origin is added to the allowlist, PrintBridge rejects browser requests from non-matching origins with 403 — even if they have the API key.

Only https:// origins can be added (plus http://localhost for dev), blocking plain-HTTP phishing pages. Adding an origin requires the user to click Allow in a native Windows dialog — a web page cannot silently add itself.

The local server uses plain HTTP on 127.0.0.1. This is standard practice for localhost IPC — Chrome, Edge, and Firefox all treat 127.0.0.1 as a secure context. Traffic never leaves the network interface and cannot be intercepted on the wire.

Your web application communicates over HTTPS on your own infrastructure. The browser's call to PrintBridge is a local process call, not a network request.

No. Print content never leaves the machine.

HTML, PDF, PNG, ZPL, ESC/POS, and all other content flows directly from your web app to the local PrintBridge API to the Windows print spooler — entirely on the same machine. Temp files used for large payloads are deleted immediately after the job completes.

PrintBridge is a local print dispatcher — it does not store, process, or transmit protected health information (PHI). Print content is a transient in-memory payload that flows from your web application to the Windows spooler and is immediately discarded.

• No PHI at rest: temp files deleted immediately after each print job
• No PHI in transit to the cloud: print payloads never leave the machine
• Access control: API key required; origin allowlist restricts which apps can print
• Audit trail: GET /logs provides timestamps, printer, format, success/fail — no content
• Runs under the logged-in Windows user account, subject to your existing AD / endpoint policies

If your organization requires a BAA or a formal vendor security questionnaire, contact security@printbridge.app.

Yes. Production builds are code-signed via Azure Trusted Signing. Windows SmartScreen recognizes the publisher and will not block installation. You can verify the signature in Properties → Digital Signatures on the .exe.

GET /status includes "appSigned": true for signed builds, letting your integration programmatically confirm it is talking to an authentic PrintBridge binary.

• Enable the origin allowlist — add only your production domain
• Store the API key in your app's secrets manager, not in client-side JS
• Restrict %APPDATA%\PrintBridge via Windows ACLs if your policy requires it
• Poll GET /logs from your application to monitor for unexpected print activity
• Keep PrintBridge updated — auto-updates check every 6 hours and install on restart
• For fleet deployments, the device heartbeat reports printer health and job success rates to your dashboard