mirror of
https://github.com/denoland/deno
synced 2024-08-25 02:57:22 +00:00
docs(security): clarify storage explosion attacks in policy (#18697)
Deno does not cover storage explosion attacks from evaluated runtime code. I've chosen the following parts for this clarification: - _Evaluated_ code - storage explosion attacks caused by services in Deno such as the HTTP server should still be covered. - Isolated - If the storage explosion attack can happen at arbitrary different files, it may leave a much more lasting impact on a targeted host system than on simply the Deno cache.
This commit is contained in:
parent
1f0360c073
commit
652694f15d
4
.github/SECURITY.md
vendored
4
.github/SECURITY.md
vendored
|
@ -48,6 +48,10 @@ may change slightly over time, but in general the model is as follows:
|
|||
that a value set in one web worker can not be accessed by another.
|
||||
- All runtime I/O is considered to be privileged and must always be guarded by a
|
||||
runtime permission. This includes filesystem access, network access, etc.
|
||||
- The only exception to this is runtime storage explosion attacks that are
|
||||
isolated to a part of the file system, caused by evaluated code (for
|
||||
example, caching big dependencies or no limits on runtime caches such as the
|
||||
[Web Cache](https://developer.mozilla.org/en-US/docs/Web/API/Cache) API).
|
||||
- Users should not be able to self-escalate their permissions without explicit
|
||||
consent.
|
||||
- I/O required to build an initial static module graph should always follow the
|
||||
|
|
Loading…
Reference in a new issue