I’ve been using other apps than Obsidian for notes and sharing, so this is nice to read and consider. But isn’t Obsidian an electron app or whatever? Electron has always seemed resource intensive and not native. JavaScript has never struck me as “secure”. Am I just out of touch?
Yes, you are responsible for all the code you ship to your users. Not pinning dependencies is asking for trouble. It is literally, "download random code from the Internet and hope for the best."
This is obviously the way to do it, assuming you have the skills and resources to operate in this manner. If you don't, then godspeed, but you have to know going in that you are trading expediency now for risk later. Risk of performance issues, security vulnerabilities, changes in behavior, etc. And when the mess inevitably comes, at whatever inopportune time, you don't really get to blame other people...
Going to preface this post by saying I use and love Obsidian, my entire life is effectively in an Obsidian vault, I pay for sync and as a user I'm extremely happy with it.
But as a developer this post is nonsense and extremely predictable [1]. We can expect countless others like it that explains how their use of these broken tools is different and just don't worry about it!
By their own linked Credits page there are 20 dependencies. Let's take one of those, electron, which itself has 3 dependencies according to npm. Picking one of those electron/get has 7 dependencies. One of those dependencies got, has 11 dependencies, one of those cacheable-request has 7 dependencies etc etc.
Now go back and pick another direct dependency of Obsidian and work your way down the dependency tree again. Does the Obsidian team review all these and who owns them? Do they trust each layer of the chain to pick up issues before it gets to them? Any one of these dependencies can be compromised. This is what it means to be. supply chain attack, you only have to quietly slip something into any one of these dependencies to have access to countless critical user data.
To be fair, the electron project likely invests some resources in reviewing it's own dependencies, because of its scale. But yeah this is a good exercise, I think we need more systems like Yocto which prioritize complete understanding of the entire product from source.
This is one way to look at it, but ignores the fact that most users use third party community plugins.
Obsidian has a truly terrible security model for plugins. As I realized while building my own, Obsidian plugins have full, unrestricted access to all files in the vault.
Obsidian could've instead opted to be more 'batteries-included', at the cost of more development effort, but instead leaves this to the community, which in turn increases the attack surface significantly.
Or it could have a browser extension like manifest that declares all permissions used by the plugin, where attempting to access a permission that's not granted gets blocked.
Both of these approaches would've led to more real security to end users than "we have few third party dependencies".
It's no worse than vscode. Sure there's permissions, but it's super common for an extension to start a process and that process can do anything it wants.
This app deals with very critical, personal, and intimate data – personal notes and professional/work-related notes, but proudly has an Electron app. This alone has seemed like a massive red flag to me.
I think it's a matter of time until we see a notable plugin in the obsidian space get caught exfiltrating data. I imagine then, after significant reputational harm, the team will start introducing safe guards. At a minimum, create some sort of verified publisher system.
Is this true? Is there any source about how many obsidian users use third party plugins? For once I don't. Moreover, obsidian by default runs in "restricted mode" which does not allow for community plugins. You have to specifically enable it to be able to install community plugins, hence I assume somebody who does that understands the risks involved. How many people even get into enabling that?
For me it is not even about security firstmost, the whole appeal of markdown is simplicity and interoperability. The more I depend on "plugins" the more I am locked in into this specific platform.
> could've instead opted to be more 'batteries-included', at the cost of more development effort, but instead leaves this to the community, which in turn increases the attack surface significantly.
My personal take is that the only way to be reasonably sure you're OK is to install as few apps as possible and then as few plugins as possible (and ideally stick to the bundled ones only). I don’t think it’s controversial, but for some reason this is not how many people think, even if in the real world you don’t give keys to your place to everyone who says they’re cool :)
I agree Obsidian plugins do nothing about safety. But I'm not sure "most users use plugins", that's not my impression from reading the subreddit. I wonder if there's any data on it?
Among others, this is a big reason I want effect systems to gain more attention. After having seen them, the idea that in most languages, the only option is that any function can do anything without keeping track of what it affects in its type signature is bonkers to me.
As someone who specifically started building Octarine, just for this reason, I understand.
Having to rely on random devs for the most basic functionality and passing it off as `community does what it wants` is weird. Either add it in yourselves, or accept the fact that given your app requires external contributors to work at a little above the basic level, there are going to be security issues.
Writing a whole blog post, and throwing shade on "other apps" that have far more dependencies than Obsidian is weird to me.
Anyway, it seems like you can't really talk bad about them, since there's a huge following that just comes at you, and that feels weird, cause they apparently can throw shade, others can't just talk back.
Yes, on desktop, Obsidian plugins can access files on your system, unless you run it in a container. On iOS, iPadOS, and Android the app is sandboxed so plugins are more constrained.
This is not unique to Obsidian. VS Code (and Cursor) work the same way despite Microsoft being a multi-trillion dollar company. This is why Obsidian ships in restricted mode and there's a full-screen warning before you turn on community plugins.
VS Code and Obsidian have similar tradeoffs, both being powerful file-based tools on the Electron stack. This fear about plugins was raised on the Obsidian forums in 2020 when Obsidian was still new, and Licat explained[1] why it’s not possible to effectively sandbox plugins without making them useless.
So... what do you do?
The drastic option is to simply not use community plugins. You don't have to leave restricted mode. For businesses there are several ways to block network access and community plugins[2]. And we're currently planning to add more IT controls via a policy.json file[3].
The option of using Obsidian without plugins is more viable in 2025 than it was in 2020, as the app has become more full-featured. And we're now regularly doing third-party security audits[4].
But realistically, most people want to run community plugins, and don't have the technical skills to run Obsidian in a container, nor the ability and time to review the code for every plugin update.
So the solution that appeals to us most is similar to the "Marketplace protections"[5] that Microsoft gradually implemented for VS Code. For example, implementing a trusted developer program, and automated scanning of each new plugin update. We plan to significantly revamp the community directory over the coming year and this is part of it.
Note that Obsidian is a team of 7 people. We're 100% user-supported[6] and competing with massive companies like Microsoft, Apple, Google, etc. Security audits are not cheap. Building an entire infrastructure like the one I described above is not easy. We're committing to doing it, but it wouldn't be possible without our supporters.
This doesn't make any sense to me. I've always been told you don't write anything yourself unless you absolutely have to and having a million micro-dependencies is a good thing. JavaScript and now Rust devs have been saying this for years. Surely they know what they're doing...
There is a balance to be struck. NPM in particular has been a veritable dependency hell for a long time. I don't know if it just attracts inexperienced developers, or if its security model is fundamentally flawed, but there have been soooo many supply chain attacks using NPM that being extra careful is very much warranted.
If the obsidian team did a 2 hour q&a livestream every week, I'd watch every one (or at least get the AI summary). One of my favorite pieces of software ever.
I love Obsidian dearly, but if you build an app that's only really useful with plugins, and that has a horrifyingly bad security model for plugins and little to no assurance of integrity of the plugins...
Maybe, just maybe, don't give fullmouthed advice on reducing risk in the supply chain.
'It may sound obvious but the
primary way we reduce the risk of
supply chain attacks is to avoid depending on third-party code."
What a horribly disingenuous statement, for a product that isn't remotely usable without 3rd-party plugins. The "Obsidian" product would be more aptly named "Mass Data Exfiltration Facilitator Pro".
That's just...what? It's highly usable without plugins. Yes, I use plugins...but that's by choice. Obsidian is still a superior Markdown editor with backlink support, plugins or not.
I think you and your fellow commenters are missing the point. The degree to which Obsidian is "a superior Markdown editor with backlink support" can be debated. What I'm saying is that actual usability, in this context, is not a matter of opinion -- see ISO 9241-210, ISO/IEC 25010, etc.. Having said that, I'm glad you're happy.
Absolutely love Obsidian but had to stop using it because Electron apps don't play well with Wayland. After lots of tinkering around with flags and settings for compatibility layers, it became obvious that it would never work seamlessly like it did on Windows (and probably does on x11). So it was either give up Wayland compositors or give up Obsidian. Luckily I don't use any plugins, so moving to other software was easy, but I still would prefer Obsidian. Electron's "works everywhere" works about as good as Java's "works everywhere", which is to say it works great, until it doesn't, at which point it's a mess of tinkering.
If you use Wayland and it works for you, that's great, but it's not my experience.
Was hoping they outlined their approach to handling potentially compromised packages running on dev machines prior to even shipping. That seems like a much harder problem to solve.
Can’t wait for “implements mechanism to delay application of new patches” to start showing up compliance checklists. My procrastination will finally pay off!
I installed an AppArmor profile for Obsidian. For an application that displays text files, it needed a lot of permissions. It would refuse to run without network access.
You can install Obsidian flatpak and lock it down with flatseal.
These practices are very similar to what I've done in the past, for a large, sensitive system, and they worked very well.
(IIUC, we actually were the first to get a certain certification for cloud deployment, maybe because we had a good handle on this and other factors.)
From the language-specific network package manager, I pulled the small number of third-party packages we used into the filesystem tree of system's repo, and audited each new version. And I disabled the network package manager in the development and deployment environments, to make it much harder for people to add in dependencies accidentally.
Dependencies outside this were either from the Linux distro (nice, because well-managed security updates), or go in the `vendor` or `ots` (off-the-shelf) trees of the repo (and are monitored for security updates).
Though, I look at some of the Python, JS, or Rust dependency explosions I sometimes see -- all dependent on being hooked up to the language's network package manager, with many people adding these cavalierly -- and it becomes a much harder problem.
72 comments
[ 5.0 ms ] story [ 78.7 ms ] threadBut as a developer this post is nonsense and extremely predictable [1]. We can expect countless others like it that explains how their use of these broken tools is different and just don't worry about it!
By their own linked Credits page there are 20 dependencies. Let's take one of those, electron, which itself has 3 dependencies according to npm. Picking one of those electron/get has 7 dependencies. One of those dependencies got, has 11 dependencies, one of those cacheable-request has 7 dependencies etc etc.
Now go back and pick another direct dependency of Obsidian and work your way down the dependency tree again. Does the Obsidian team review all these and who owns them? Do they trust each layer of the chain to pick up issues before it gets to them? Any one of these dependencies can be compromised. This is what it means to be. supply chain attack, you only have to quietly slip something into any one of these dependencies to have access to countless critical user data.
[1] https://drewdevault.com/2025/09/17/2025-09-17-An-impossible-...
Obsidian has a truly terrible security model for plugins. As I realized while building my own, Obsidian plugins have full, unrestricted access to all files in the vault.
Obsidian could've instead opted to be more 'batteries-included', at the cost of more development effort, but instead leaves this to the community, which in turn increases the attack surface significantly.
Or it could have a browser extension like manifest that declares all permissions used by the plugin, where attempting to access a permission that's not granted gets blocked.
Both of these approaches would've led to more real security to end users than "we have few third party dependencies".
Is this true? Is there any source about how many obsidian users use third party plugins? For once I don't. Moreover, obsidian by default runs in "restricted mode" which does not allow for community plugins. You have to specifically enable it to be able to install community plugins, hence I assume somebody who does that understands the risks involved. How many people even get into enabling that?
For me it is not even about security firstmost, the whole appeal of markdown is simplicity and interoperability. The more I depend on "plugins" the more I am locked in into this specific platform.
Ah, the WordPress model.
Having to rely on random devs for the most basic functionality and passing it off as `community does what it wants` is weird. Either add it in yourselves, or accept the fact that given your app requires external contributors to work at a little above the basic level, there are going to be security issues.
Writing a whole blog post, and throwing shade on "other apps" that have far more dependencies than Obsidian is weird to me.
Anyway, it seems like you can't really talk bad about them, since there's a huge following that just comes at you, and that feels weird, cause they apparently can throw shade, others can't just talk back.
Yes, on desktop, Obsidian plugins can access files on your system, unless you run it in a container. On iOS, iPadOS, and Android the app is sandboxed so plugins are more constrained.
This is not unique to Obsidian. VS Code (and Cursor) work the same way despite Microsoft being a multi-trillion dollar company. This is why Obsidian ships in restricted mode and there's a full-screen warning before you turn on community plugins.
VS Code and Obsidian have similar tradeoffs, both being powerful file-based tools on the Electron stack. This fear about plugins was raised on the Obsidian forums in 2020 when Obsidian was still new, and Licat explained[1] why it’s not possible to effectively sandbox plugins without making them useless.
So... what do you do?
The drastic option is to simply not use community plugins. You don't have to leave restricted mode. For businesses there are several ways to block network access and community plugins[2]. And we're currently planning to add more IT controls via a policy.json file[3].
The option of using Obsidian without plugins is more viable in 2025 than it was in 2020, as the app has become more full-featured. And we're now regularly doing third-party security audits[4].
But realistically, most people want to run community plugins, and don't have the technical skills to run Obsidian in a container, nor the ability and time to review the code for every plugin update.
So the solution that appeals to us most is similar to the "Marketplace protections"[5] that Microsoft gradually implemented for VS Code. For example, implementing a trusted developer program, and automated scanning of each new plugin update. We plan to significantly revamp the community directory over the coming year and this is part of it.
Note that Obsidian is a team of 7 people. We're 100% user-supported[6] and competing with massive companies like Microsoft, Apple, Google, etc. Security audits are not cheap. Building an entire infrastructure like the one I described above is not easy. We're committing to doing it, but it wouldn't be possible without our supporters.
[1] https://forum.obsidian.md/t/security-of-the-plugins/7544/3
[2] https://help.obsidian.md/teams/deploy
[3] https://x.com/kepano/status/1957927003254059290
[4] https://obsidian.md/security
[5] https://code.visualstudio.com/docs/configure/extensions/exte...
[6] https://stephango.com/vcware
While we're on the topic: what's your default markdown handler on Windows?
Maybe, just maybe, don't give fullmouthed advice on reducing risk in the supply chain.
What a horribly disingenuous statement, for a product that isn't remotely usable without 3rd-party plugins. The "Obsidian" product would be more aptly named "Mass Data Exfiltration Facilitator Pro".
That's not even remotely true. Obsidian out-of-the-box is very usable, covers pretty much all use cases for a note-taking software.
I've been using it for ages, and I haven't needed to turn on the Community Plugins switch for anything.
Usually the people I see with tons of Obsidian plugins are people who think "just one more plugin" is what stands between them and productivity.
If you use Wayland and it works for you, that's great, but it's not my experience.
https://npmgraph.js.org/?q=express
Eslint with such wonderful dependencies like is-glob smh
Can’t wait for “implements mechanism to delay application of new patches” to start showing up compliance checklists. My procrastination will finally pay off!
You can install Obsidian flatpak and lock it down with flatseal.
(IIUC, we actually were the first to get a certain certification for cloud deployment, maybe because we had a good handle on this and other factors.)
From the language-specific network package manager, I pulled the small number of third-party packages we used into the filesystem tree of system's repo, and audited each new version. And I disabled the network package manager in the development and deployment environments, to make it much harder for people to add in dependencies accidentally.
Dependencies outside this were either from the Linux distro (nice, because well-managed security updates), or go in the `vendor` or `ots` (off-the-shelf) trees of the repo (and are monitored for security updates).
Though, I look at some of the Python, JS, or Rust dependency explosions I sometimes see -- all dependent on being hooked up to the language's network package manager, with many people adding these cavalierly -- and it becomes a much harder problem.