Skip to main content
BosonMail handles business email, which often includes sensitive content and recipient data. This page covers practical steps to keep your integration secure.

Server-side only

The BosonMail SDK is designed for server-side use. Never expose API keys in browser bundles, mobile apps, or client-side JavaScript.
Do not prefix environment variables with NEXT_PUBLIC_, VITE_, REACT_APP_, or similar. Those prefixes embed values into client-side code. Use a server-only variable such as BOSONMAIL_API_KEY.
If you need to send email from a browser form, submit the form to your own backend, validate it, and call the SDK server-side.

Secret storage

Store API keys in environment variables or a dedicated secrets manager. Validate the key at startup and fail fast if it is missing.
lib/bosonmail.ts
For platform-specific guidance, see Authentication and API keys.

Do not log credentials

The BosonMailClient instance exposes apiKey as a readonly public property. Avoid logging the client object directly, or redact the key first.
Also avoid logging email content, recipient lists, and attachment filenames at info level. Treat them as sensitive data.

Prevent open relay

If your application accepts user input to determine the recipient or content of an email, protect against abuse:
  • Authenticate send endpoints: only signed-in or authorized users should trigger emails.
  • Fix the recipient server-side: for contact forms, do not let the user supply the to address. Hardcode it or map it from a trusted identifier.
  • Rate limit: apply per-user or per-IP rate limits on endpoints that send email.
  • Use CAPTCHA on public forms to reduce automated abuse.

Sanitize user input

The SDK passes subject through as-is after trimming. Escape or strip user-supplied content before placing it in HTML bodies or subjects.
As defense in depth, strip newline characters from user-supplied subjects to prevent header injection.

Attachment safety

  • Validate file types and sizes in your application before passing them to the SDK.
  • Reject executable file types (.exe, .bat, .sh) at the application layer.
  • Scan attachments with an antivirus or content scanner if your use case requires it.
  • The SDK enforces a 10 MB per-file and 20 MB total limit, but application-level checks should run first.

HTTPS only

The SDK requires baseUrl to be an absolute HTTP(S) URL. Always use https:// in production. The default base URL is https://webmail.bosonware.com/api/v1.

Dependency hygiene

The BosonMail SDK has zero runtime dependencies, which reduces supply-chain risk. Still, follow these practices:
  • Pin the SDK version in package.json and use lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml).
  • Run npm audit regularly.
  • Verify the package name exactly: @bosonware-ent/bosonmail. Typosquatting is a real risk.
  • Upgrade promptly when security fixes are released. See the Changelog for release notes.

Incident response

If you suspect a key leak or unauthorized usage:
  1. Revoke the key immediately via the dashboard or by contacting support@bosonware.com.
  2. Rotate to a new key.
  3. Audit recent sends and status checks for unexpected recipients or content.
  4. Review application logs for signs of injection or abuse.

Next steps

Authentication and API keys

Key scopes, storage, rotation, and leak response.

Troubleshooting

Fix common runtime and configuration issues.

Error codes

Understand every error the SDK can return.

Production best practices

Queues, retries, and safe sending patterns at scale.