Security Statement

What this document is

It is a plain description of how the extension works where security is concerned: what it can reach, how it stores what it stores, what travels over the network, and which parts you should not lean on. It exists so that you — or the security team that has to approve your tooling — can make an informed decision in ten minutes.

What ORGanizer is, and is not

ORGanizer is a browser extension that does three kinds of thing:

• It marks up your browser. Tab titles and favicon colours per ORG. This touches nothing but the tab.
• It keeps a list of logins so you can open an ORG without retyping a password.
• It talks to your Salesforce ORGs with your own session, through the Salesforce APIs, on your behalf: Quick Links, the Quick Console, Health Monitor, Access Lens and the page helpers.

Everything ORGanizer does, it does as you. It holds no privileges of its own inside your ORGs: it uses your session, so it can see exactly what you can see and change exactly what you can change — no more, and no less.

Browser permissions

These are granted when you install the extension:

Plus a small set of hosts that are ORGanizer's own, never Salesforce:

• api.organizer.solutions — licence and promo-code validation, and the licence checks of a device signed in with an ORGanizer account;
• organizer.solutions — this website, for the in-popup messages, the sponsor list, the change log and the sign-in with an ORGanizer account.

Salesforce domains

ORGanizer is installed with no access to any Salesforce domain. Access is requested one ORG at a time, the first time you open that ORG, and what is requested is that ORG's specific origins — not a wildcard over Salesforce. For acme.my.salesforce.com that is:

https://acme.my.salesforce.com/*
https://acme.lightning.force.com/*
https://acme.vf.force.com/*
https://acme.file.force.com/*
https://acme.my.salesforce-setup.com/*

Sandboxes, developer and scratch ORGs get the same set with their own partition segment. Until you grant them, the extension does nothing on that ORG's pages. Everything you granted is listed in Options → Permissions, grouped by My Domain, and each group can be revoked on its own — revocation takes effect immediately.

login.salesforce.com and test.salesforce.com are offered separately on first run, because a stored login cannot be opened before its ORG's own domain is granted. You can decline. api.status.salesforce.com is requested only if you open the Health Monitor, which reads instance status from Salesforce's public status service.

The full mechanics are in the documentation.

Credentials and encryption

Logins live in your browser's extension storage. Nothing of them is uploaded to us: no server of ours holds your Salesforce credentials — not even the ORGanizer account the extension can sign in with for its licence, which knows nothing of your logins.

With encryption enabled

Each password and each security token is encrypted individually, through the browser's Web Crypto API:

Keep unlocked

The browser puts the extension's background to sleep after about 30 seconds without activity, and a key held only in its memory goes with it: how long the extension stayed unlocked was the browser's decision — thirty seconds, or hours while something kept it busy. Keep unlocked (from version 1.0.22, Options → Encryption) makes it yours. It is on by default, with a 5-minute limit:

• the key is wrapped with AES-GCM by a second, random, non-extractable key;
• the wrapped key is kept in the browser's session storage, which lives in memory and is cleared when the browser closes, and which content scripts cannot read;
• the random key is kept in the extension's IndexedDB database, on disk. Neither half can decrypt anything without the other, and your master password is stored nowhere;
• the session locks after the chosen minutes without use of a saved password (1 minute to 24 hours), checked before every use, when the background wakes up and by a timer; locking, the time running out, turning the setting off and closing the browser delete both halves.

Cryptographically nothing changes, and the same attackers stay out: code that can run as the extension could already ask it to decrypt. What changes is how long the session stays open, now bounded by the limit you choose. On a machine other people can reach, lower the minutes or turn Keep unlocked off.

Unlock with a passkey

From version 1.0.22 (Options → Encryption, off until you add one), a passkey can open the key instead of your master password: your fingerprint, face, device PIN or a security key. It is local to the browser and to the extension, and has nothing to do with the ORGanizer account:

• the passkey's PRF extension gives a 32-byte secret that only the authenticator can produce again; HKDF-SHA-256 turns it into an AES-GCM 256 key that wraps the encryption key. Only the wrapped key is stored, in the extension's local storage: never synced, backed up or exported, and it opens nothing without the passkey;
• user verification is required: a touch without your fingerprint, face or PIN is refused, and your biometrics stay on your device;
• an unwrapped key counts only once it opens the same verifier your password does; a passkey added before the password changed, here or on a synced browser, is dropped;
• the master password stays the root: adding or removing a passkey asks for it, it is asked once every 24 hours, and changing it or turning encryption off removes every passkey. A passkey cannot recover a forgotten password;
• the passkeys belong to orgnz-extension.organizer.solutions, an optional permission asked when the first passkey is added. The extension never contacts it, and a passkey of that domain is never offered to this website.

What it changes: someone holding a copy of your browser profile gains nothing they did not have before. Someone who can unlock your device and your passkey can unlock ORGanizer on that browser, as they could if they knew your master password, and only within a day of your last password. A passkey your provider syncs to other devices unlocks ORGanizer only on the browsers where you added it.

With encryption disabled

Synchronised logins

Marking a login as synced places it in your browser's sync storage, from where your browser vendor — Google, Microsoft, Mozilla — replicates it to your other signed-in profiles, under their infrastructure and their policy, not ours. If encryption is on, what is replicated is already encrypted. If you would rather nothing left the device, leave logins unsynced.

Backups and exports

Automatic backups are local to one browser and re-encrypted when you change your master password. The Import / Export file is written in the clear, on purpose, so that it can be read and edited — which makes it a plain-text copy of your credential store. Treat an export like the credentials themselves: encrypt it, move it deliberately, delete it when done.

Sessions and ORG data

The tools read your Salesforce session from the browser's cookie store and call the Salesforce APIs directly, browser to ORG. We are never in that path, and no ORG data reaches our servers.

One flow is worth knowing about, and it does not apply to every login: opening a stored login configured for Login with token or Login with OAuth hands Salesforce the session id it got back from the SOAP or REST API in a URL, because that is how Salesforce's own session-confirmation handoff (frontdoor.jsp) works. A plain username-and-password login does not go through this step. Those handoff URLs can end up in browser history. They are short-lived, but they are not nothing.

Signing in with an ORGanizer account

From version 1.0.22 a device can use a licence through the community account it is linked to, instead of its key (see the documentation). That account is for the licence and the community only: it holds no Salesforce credential and no ORG data.

• Your password is typed on this website, never in the extension. It is stored as a scrypt hash with a secret key kept apart from the database; wrong attempts are limited, and the log-in form is checked by reCAPTCHA.
• OAuth 2.1, authorization code with PKCE. The site sends the code back only to the extension's own page, and only the extension that started the sign-in can trade it.
• Short-lived tokens. The extension gets an access token that lasts minutes and a refresh token that changes at every use. The site keeps only one-way hashes of them; the extension keeps them on the device, out of sync, backups and exports.
• A signed licence answer. The licence's state reaches the extension signed (ES256) by our licence server, and the extension checks the signature against a public key it carries. The answer carries no email address.
• Devices end on our side. A device signed out in the extension, or removed in My licenses, loses the licence at its next check. Changing the account's password does not sign devices out: remove them in My licenses.
• The community panel. The extension's community panel frames this website's own pages, which can be framed by the extension and by nothing else. It is signed in with a one-time ticket the extension gets for its access token (60 seconds, usable once), never with the token itself, and the panel's session ends with the device. Only intents cross between the panel and the extension (open this page, sign in), never a token, and nothing of your ORGs or of the page you are on ever reaches the panel.
• From the panel to the website. View online and My account open this website already signed in, with a one-time ticket of its own. Because a ticket is a sign-in, the website signs in by itself only when the extension opened the tab and no other account is logged in there; otherwise it names the account and asks you to confirm, so a link from elsewhere cannot sign you into someone else's account.

What leaves your browser

That is the complete list. The extension currently sends no usage analytics. Google Analytics was removed with the move to Manifest V3 and has not come back; the googleapis.com host is gone from the manifest. A sponsor banner click is a link you opened, not telemetry: showing a banner only loads its image, and what the click itself carries is the row above.

If that changes — and it might, to understand which features are worth building on rather than to profile anyone — it will be feature-usage telemetry, never the content of your ORG data or your credentials, and it will come with three things in place before it ships: advance notice here and in the change log, a way to opt out, and a way to see exactly what an anonymised event looks like. This website does use analytics and advertising — see the Privacy Policy.

What we recommend

• Turn encryption on, with a password you do not use anywhere else, before you store the first login.
• Use ORGanizer for the environments where a leak is an inconvenience, not an incident: scratch orgs, developer editions, sandboxes, the test users you rotate through.
• Grant one ORG at a time and revoke what you no longer work on, from Options → Permissions.
• Prefer Login with OAuth where you can: the password is never stored, and access can be revoked from the ORG.
• Lock your machine. Encryption protects you against a stolen disk or a copied profile, not against someone sitting at your unlocked laptop while ORGanizer is unlocked. Keep the Keep unlocked limit short, or turn it off, where that is a risk; a passkey is only as safe as your device's own lock.
• Keep the extension updated. Security fixes ship through the stores like anything else.
• Take an export before a hard reset or a password change — and delete it afterwards.
• Read the Health Monitor's cost estimate before running it against a production ORG with a tight API allowance.

What we advise against

• Do not store production admin credentials, break-glass accounts, or any login whose compromise would be a reportable incident.
• Do not store anything covered by an NDA, or that your company's security policy has an opinion about. If you would have to ask, the answer is no.
• Do not use it as your team's shared credential store. It is per-person, per-browser, by design.
• Do not run it with encryption off and assume the stored values are protected. They are not.
• Do not install it on a shared or kiosk machine, or on a profile other people can sign into.
• Do not attach an export or a debug log to a support request without reading it first — the export carries credentials in the clear, and a log can carry ORG identifiers and query text.
• Do not point write-capable tools at production casually. Anonymous Apex, profile deploys and IP whitelisting are the same actions you could take by hand, just faster.

Known limits

Stated plainly, because this is the part that matters:

• A compromised browser profile is a compromised extension. Anything running with your profile's privileges — malware, a malicious extension, someone at your unlocked desk — is inside the trust boundary. Encryption raises the cost; it does not remove the exposure.
• Your data is only as durable as your browser profile. Nothing of it is on our servers, so a profile that is lost, reset or corrupted takes the logins and configurations with it, and there is nothing for us to restore.
• Encryption off means unprotected. Obfuscation keyed to the extension's own identifier is not confidentiality.
• Export files are plain text, by design.
• Sync storage is your browser vendor's. Its confidentiality is theirs to define, not ours.
• Your ORGanizer account can sign devices in on your licences. Whoever logs in to it can use them, up to their number of installations. Give it a password of its own, and remove in My licenses any device you do not recognise.
• The extension is not formally certified or continuously audited. There is no SOC 2, no ISO 27001, no bug bounty. One maintainer, public source reviews, and the store review processes.
• Login with token and Login with OAuth hand off a session id through a URL, as described above, because that is how Salesforce's own frontdoor.jsp confirmation works. A plain username-and-password login does not.
• SOAP username-password login is being retired by Salesforce and is already disabled on some ORGs. Login with token will stop working there.
• Third-party dependencies are a standing attack surface, and 1.0 has been actively cutting them down — fewer bundled libraries, less code doing things the extension does not actually need. That work continues: the smaller the surface, the fewer places a supply-chain problem has to hide.

Independent review

Ahead of 1.0 the codebase was put through several independent security reviews, covering architecture and threat model, cryptography and secret handling, code-level issues, and backend and dependency exposure. The results were consolidated and drove a large part of what 1.0 actually is:

• the credential encryption was rebuilt from scratch on the Web Crypto API, replacing a derivation that was far too weak;
• permissions were cut back, and Salesforce access moved to the opt-in, per-ORG model;
• the features that carried the most exposure for the least benefit — Google Drive backup, the Connector integration, the Google sign-in behind them — were removed rather than patched;
• the claims this document makes were rewritten to match what the code actually does, which is how you come to be reading this version of it.

Not everything raised has been addressed; what is still open is summarised honestly under known limits. We are not publishing an exploitable finding list, and a review is a snapshot rather than a guarantee.

Verify it yourself

You do not have to take this document's word for any of it:

• The permission list is in your browser: chrome://extensions, edge://extensions or about:addons → ORGanizer → Details. That is the authoritative list for the build you actually installed.
• The granted domains are in Options → Permissions, and you can revoke any of them there.
• The network traffic is visible in your browser's developer tools, including everything the background worker sends.
• The stored data can be inspected with the extension's own export, which writes the logins, ORG configurations and settings it holds; the sign-in tokens and the Health Monitor's saved scans stay out of it by design.

If what you find does not match what is written here, that is a bug in this document and we want to hear about it.

Reporting a problem

Use the support form. For something you believe is a security issue, say so in the first line and please do not post the details publicly until it has been looked at. Include what you did, what happened, and the browser and extension version — and strip anything sensitive from what you attach.

There is no bug bounty. There is one maintainer who reads everything and takes this seriously.

What changed since 2023

The previous Security Statement was dated 17 July 2023 and described a version of the extension that no longer exists. If you read it, these are the parts that are no longer true:

See also the Privacy Policy, the EULA and the change log.