Firefox is the least secure among mainstream browsers due to its weaker sandbox and significantly less robust exploit protections.
Its smaller market share and insufficient monitoring for exploits result in fewer detected exploits, which doesn't equate to increased safety or security.
Additionally, Firefox's content sandbox is notably weaker across various platforms.
Their sandbox also doesn't have a full site isolation implementation so it can't fully defend sites from each other yet. Firefox sandbox does less and is much weaker but there are other weaknesses.
There are other major advantages of Chromium: Oilpan + MiraclePtr + PartitionAlloc defending against the main sources of heap corruption, no real equivalent in Firefox.
Oilpan (garbage collection for C++ objects) and MiraclePtr (use-after-free protection for non-Oilpan objects) are massive defenses against the main forms of memory corruption bugs in browsers (use-after-free). PartitionAlloc is also a major upgrade over jemalloc in Firefox.
Chromium’s new V8 sandbox isolates the JavaScript engine’s heap memory, preventing compromised code from affecting other process memory. Firefox has no equivalent layer.
v8.dev/blog/sandbox
thehackernews.com/2024/04/google
Seccomp-BPF is a Linux sandboxing technology that enables the restriction of system calls available to a process, significantly reducing the kernel's attack surface and serving as a fundamental component of most Linux sandboxing mechanisms.
Firefox is not utilizing it the same way Chromium is.
searchfox.org/mozilla-centra
bugzilla.mozilla.org/show_bug.cgi?i
This is the main way out of the sandbox and is leveraged in most real world browser exploits.
It's easier to exploit the kernel than the browser broker process in practice.
Fission (Firefox's Site-isolation project) inherits the security weaknesses of Firefox’s content process sandbox and is not a comprehensive solution.
bugzilla.mozilla.org/show_bug.cgi?i
bugzilla.mozilla.org/show_bug.cgi?i
Firefox doesn't deploy basic mitigations like type-based CFI anyway. Since it doesn't even use Clang CFI yet, it really says a lot about it.
bugzilla.mozilla.org/show_bug.cgi?i
They have yet to implement GPU process sandbox on Linux.
bugzilla.mozilla.org/show_bug.cgi?i
bugzilla.mozilla.org/show_bug.cgi?i
bugzilla.mozilla.org/show_bug.cgi?i
Chromium, runs all graphics operations (OpenGL/Vulkan/Direct3D calls) in isolation from renderers and browser.
Chromium, runs all graphics operations (OpenGL/Vulkan/Direct3D calls) in isolation from renderers and browser.
The GPU process operates in a sandbox where Layer 1 validates commands from renderer processes before Layer 2 executes them on the hardware, providing a security barrier between untrusted content and direct GPU access.
developer.chrome.com/docs/chromium/
mozjemalloc is significantly less hardened compared to PartitionAlloc.
Metadata isolation PartitionAlloc = yes, jemalloc no Freelist encryption PartitionAlloc = yes, jemalloc no Guard pages per slab PartitionAlloc = yes, jemalloc no UAF quarantine PartitionAlloc = yes, and you guessed right! jemalloc no
chromium.googlesource.com/chromium/src/+
github.com/scrapy/base-ch
Mozjemalloc takes a different approach than newer allocators like SJMalloc that store metadata out-of-band.
Oilpan eliminates manual memory management errors by automatically tracking object lifetimes via conservative stack scanning and cross-component tracing with V8.
Oilpan (Garbage Collector), Automatically prevents use-after-free in DOM/JS-bound objects via tracing, eliminates manual delete errors through conservative stack scanning.
This is mandatory for all Blink/V8-integrated code.
Firefox (mozjemalloc) has no active mitigation.
MiraclePtr alone reduced 57% of exploitable use-after-free bugs in Chromium's renderer process.
Firefox for Android lacks internal sandboxing entirely, relying solely on basic OS-level app containment vs Chromium's layered defense using 'isolatedProcess' flags
Without android:isolatedProcess (current GeckoView situation):
Access the same permissions as your main app. This means if your app has permissions for camera, location, storage, etc., the browser engine (GeckoView) process can also use these permissions.
This is in contrast to an isolated process, which would run under a special process that is isolated from the rest of the system and has no permissions of its own.
The lack of process isolation in GeckoView stands as a security limitation compared to Chromium-based browsers that implement proper isolation.
bugzilla.mozilla.org/show_bug.cgi?i
grapheneos.org/usage#web-brow
Moz/Firefox is not "fine" it's hot garbage, their architecture is a mess, probably the worst browser architecture I've ever seen.
They are always late to support the latest web API's.
They can't even handle gradients.