Security at InboxReader

Outlook and Gmail: OAuth, no email passwords

Outlook and Gmail mailboxes are connected with Microsoft or Google’s OAuth 2.0 authorization-code flow with PKCE. You sign in on your provider’s own page; InboxReader never sees, asks for or stores those passwords. The sign-in flow is protected against cross-site request forgery with a signed, expiring state value that must match a short-lived, encrypted browser cookie and the signed-in InboxReader account.

Read-only Microsoft permissions

• Mail.Read — read messages; InboxReader displays only Inbox and Junk Email.
• User.Read — identify the connected mailbox.
• offline_access — keep access without repeated sign-ins.

InboxReader does not request Mail.Send, Mail.ReadWrite or application-wide permissions.

For Gmail, InboxReader requests gmail.readonly and basic Google identity scopes. Gmail readers display only Inbox and Spam; send, modify, delete and attachment-download operations are not implemented.

Other providers: IMAP with app passwords

AOL, Yahoo, iCloud, GMX, mail.com, Fastmail, Yandex, Zoho, hosting providers and company mail servers connect over IMAP. Where the provider offers them, InboxReader asks for an app password instead of your main password.

• The password is encrypted with AES-256-GCM before it is stored, is never sent back to your browser and is excluded from logs. It is saved only after a successful sign-in.
• Connections always use TLS (port 993) or STARTTLS (port 143) with certificate verification. A password is never sent over an unencrypted connection.
• Folders are opened read-only and messages are fetched without marking them as read. Send, move and delete operations are not implemented.
• Only public mail servers are accepted: server names that resolve to private or internal network addresses are refused.

Most providers cannot limit an app password to reading. InboxReader only reads, but anyone holding the password could do more, so delete the app password at your provider if you stop using InboxReader or suspect a problem.

Encrypted credentials

Mailbox refresh and access tokens and IMAP passwords are encrypted with AES-256-GCM (authenticated encryption) before they are written to the database. The encryption key lives in the server environment, separate from the database, and supports rotation. Credentials are never sent to your browser and are excluded from logs.

Hashed reader tokens

Each reader link contains 256 bits of cryptographically secure randomness. InboxReader looks links up by a SHA-256 hash of the secret. To let you copy a link again from your dashboard, an AES-256-GCM encrypted copy is also kept; the plain secret is never stored. Reader URLs never contain database identifiers. API keys are stored only as hashes and shown once.

Revocable access

• Rotate a reader link to invalidate its old URL immediately, or disable or delete it. Optional expiry, session limits, access codes and a verified recipient email restrict ordinary reader access.
• Disconnect a mailbox to delete its stored tokens or IMAP password. You can also revoke InboxReader in your Microsoft or Google account settings, or delete the app password at your IMAP provider.
• Revoke API keys individually and sign out of all sessions from Settings.

Safe email rendering

Email HTML is sanitized with an allowlist on the server, then shown inside a sandboxed frame that cannot run scripts, submit forms or navigate the page. Remote images are blocked by default to prevent tracking pixels, and reader pages instruct browsers not to send the reader URL to other sites.

Abuse and brute-force protection

• Rate limits on reader pages, the API, sign-in, sign-up, password reset and the provider connection flows.
• Repeated invalid reader-link requests from one network are temporarily blocked. With 256-bit secrets, guessing a valid link is not practical.
• Per-plan limits on mailboxes, links, API keys and daily API requests.

Data isolation

The database enforces Row Level Security so each signed-in user can read only their own records, and encrypted columns are not readable from the browser at all. Privileged operations run only on the server after the user is verified. Active platform administrators can inspect connected mailbox contents through audited admin views. Reader codes, recipient restrictions, expiry and message cutoffs do not restrict those views. Provider authorizations still apply.

HTTPS required

Production deployments must be served over HTTPS. InboxReader sends HSTS and a strict set of security headers, including a Content Security Policy and clickjacking protection.

Known limitations

• Anyone with a valid reader URL may be able to view the mailboxes assigned to it. Treat it like a password and rotate it if it is exposed.
• Reader URLs can be kept in browser history, bookmarks and the request logs of hosting infrastructure.
• InboxReader cannot protect a device that is already compromised, or links that were shared intentionally.
• Access depends on your email provider. Microsoft or Google can revoke authorizations (for example after a password change), and IMAP providers can expire app passwords or switch IMAP access off; both require reconnecting.
• An IMAP app password usually allows full mailbox access at the provider. It is protected by encryption, but if both our database and our encryption key were compromised it could be misused until you revoke it.

Reporting a vulnerability

Please report security issues to aymenlasfar@hotmail.com. Include steps to reproduce and avoid accessing data that is not yours. We will acknowledge reports and keep you updated on fixes.