> All APIs must robustly defend against malicious content, this is not something unique to WebGL and WebGPU.
This is not the case for C/C++ APIs. A native code application using your API can already execute arbitrary code on your computer, so the library implementing eg OpenGL is not expected to be a security boundary and does not need to defend against for example memory safety bugs to get RCE, info leakage, etc by for example sending in booby trapped pointers or sending in crafted inputs designed to trigger bugs in your API internals.
The kernel side stuff is of course supposed to be more robust but also contains a much smaller amount of code than the user facing graphics API. And robustness there is not taken as seriously because they're not directly internet-facing interfaces so browsers can't rely on correctness any protections there.
Which brings us to: drivers throughout the stack are generally very buggy, and WebGL/WebGPU implementations also have to take responsibility for preventing exploitation of those bugs by web content, sometimes at rather big performance cost.
To see what it's like you might browse https://chromereleases.googleblog.com/ and search for WebGPU and WebGL mentions and bug bounty payouts in the vulnerabilities such as
[$10000.0] [448294721] High CVE-2025-14765 Use after free in WebGPU.
[TBD][443906252] High CVE-2025-12725: Out of bounds write in WebGPU.
[$25000.0] [442444724] High CVE-2025-11205 Heap buffer overflow in WebGPU.
[$15000][1464038] High CVE-2023-4072: Out of bounds read and write in WebGL.
[$TBD][1506923] WebGPU High CVE-2024-0225
etc.
C/C++ memory safety is hard, even when you're the biggest browser vendor trying your hardest to expose C APIs to JS bindings safely.
There were a lot of WebGL vulnerabilities in a constant stream as well earlier, before WebGPU became more lucrative for bug bounties.
This is not the case for C/C++ APIs. A native code application using your API can already execute arbitrary code on your computer, so the library implementing eg OpenGL is not expected to be a security boundary and does not need to defend against for example memory safety bugs to get RCE, info leakage, etc by for example sending in booby trapped pointers or sending in crafted inputs designed to trigger bugs in your API internals.
The kernel side stuff is of course supposed to be more robust but also contains a much smaller amount of code than the user facing graphics API. And robustness there is not taken as seriously because they're not directly internet-facing interfaces so browsers can't rely on correctness any protections there.
Which brings us to: drivers throughout the stack are generally very buggy, and WebGL/WebGPU implementations also have to take responsibility for preventing exploitation of those bugs by web content, sometimes at rather big performance cost.
To see what it's like you might browse https://chromereleases.googleblog.com/ and search for WebGPU and WebGL mentions and bug bounty payouts in the vulnerabilities such as
[$10000.0] [448294721] High CVE-2025-14765 Use after free in WebGPU.
[TBD][443906252] High CVE-2025-12725: Out of bounds write in WebGPU.
[$25000.0] [442444724] High CVE-2025-11205 Heap buffer overflow in WebGPU.
[$15000][1464038] High CVE-2023-4072: Out of bounds read and write in WebGL.
[$TBD][1506923] WebGPU High CVE-2024-0225
etc.
C/C++ memory safety is hard, even when you're the biggest browser vendor trying your hardest to expose C APIs to JS bindings safely.
There were a lot of WebGL vulnerabilities in a constant stream as well earlier, before WebGPU became more lucrative for bug bounties.