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;
• organizer.solutions — this website, for the in-popup messages and the change log.

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 is uploaded to us — there is no ORGanizer account, and no server holding your credentials.

With encryption enabled

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

The practical consequence of that last row: when the browser closes, the extension reloads or the worker goes idle, the key is gone and you are asked for your master password again. That is deliberate.

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.

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: nothing is sent while a banner is merely on screen, 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. The in-memory key protects you against a stolen disk, not against someone sitting at your unlocked laptop.
• 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. The in-memory key raises the cost; it does not remove the exposure.
• 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.
• 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 exactly what it holds.

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.