docs: update SECURITY.md

Adding some feedback based on AI security reports to help guide them towards what is and is not a legitimate vulnerability.

Author: dgp1130

SECURITY.md

@@ -1,3 +1,33 @@
 Angular is part of Google [Open Source Software Vulnerability Reward Program](https://bughunters.google.com/about/rules/6521337925468160/google-open-source-software-vulnerability-reward-program-rules). For vulnerabilities in Angular, please submit your report [here](https://bughunters.google.com/report).
 
 For more information, check out [Angular's security policy](https://angular.dev/best-practices/security).
+
+## Policies
+
+The following defines some team policies around what does and does not constitute a security vulnerability.
+
+- Prototype pollution is itself a DoS vulnerability.
+  - An attacker could pollute any symbol into the wrong type and cause an error, nothing we can do will prevent that.
+  - Therefore we don't care about any DoS vulnerability which relies on prototype pollution as a precondition.
+- We trust the user's source code.
+  - "A malicious repository can execute untrusted code" is not a viable attack vector.
+  - A malicious repository could always rebind `node_modules/.bin/ng` to do something malicious, nothing we do can prevent that.
+  - We assume it is always unsafe to run an untrusted repository outside of a sandbox.
+- DoS attacks which break only the attacker's client are not security issues.
+  - Exception: DoS attacks which waste server resources significantly beyond the cost of the attacker's request may be security issues.
+- Memory leaks are considered general bugs, not DOS vulnerabilities.
+  - While any memory leak is technically a DOS vulnerability in SSR, these are generally low enough impact to not be considered security issues.
+- Our public API contract is defined by our TS types, any issue which requires breaking those types (ex. via a cast to any) falls outside Angular's support.
+  - Ex. It may be possible to leak user state by attaching it to some global data structure in SSR, but we do not consider this to be a valid vulnerability if you have to escape TS types to do it.
+
+## Invariants
+
+The following are invariants about Angular's technical infrastructure which limit some potential attack vectors. These statements are asserted by humans, not proven in any formal means. However, any security report should assume them to be true unless and until it can conclusively prove them to be false in an attack. If one of these statements invalidates a security report, that report bears the burden of conclusively demonstrating the statement to be false in its reproduction.
+
+- Zones don't leak across SSR requests (except for the root)
+  - Every request gets its own Zone, so data stored on the Zone is unique to that user, no intrinsic risk of leaking user data from one request to an attacker's request.
+- Injectors are not shared between applications.
+  - SSR always creates a new ApplicationRef and root services, no intrinsic risk of leaking user data from one request to an attacker's request.
+  - Exception: Module-scoped data is shared and is a potential vector for data leakage.
+- SSR automatically catches all exceptions and issues a 500 to the current request, meaning an attacker triggering an uncaught exception is not a DoS attack.
+- `ngDevMode` / `ngServerMode` are set at compile time in production deployments and cannot be manipulated by attackers.