Safety and Protection Against DOS Attacks
For scripting systems open to untrusted user-land scripts, it is always best to limit the amount of resources used by a script so that it does not consume more resources that it is allowed to.
These are common vectors for Denial of Service (DOS) attacks.
Most Important Resources
- 
Continuously grow a string, an array, a BLOB or object map until all memory is consumed. 
- 
Continuously create new variables with large data until all memory is consumed. 
- 
Continuously define new functions all memory is consumed (e.g. a simple closure ||, as short as two characters, is a function – an attractive target for DOS attacks).
- 
Deep recursive call that exhausts the call stack. 
- 
Large array or object map literal that exhausts the stack during parsing. 
- 
Degenerated deep expression with so many levels that the parser exhausts the call stack when parsing the expression; or even deeply-nested statements blocks, if nested deep enough. 
- 
Numeric overflows and/or underflows. 
- 
Divide by zero. 
- 
Bad floating-point representations. 
- 
Read from and/or write to private, secret, sensitive data. Such security breach may put the entire system at risk. 
The internals feature
The internals feature allows third-party access to Rust internal data types and functions (for
example, the AST and related types).
This is usually a Very Bad Idea™ because:
- 
Messing up Rhai’s internal data structures will easily create panics that bring down the host environment, violating the Don’t Panic guarantee. 
- 
Allowing access to internal types may open up new attack vectors. 
- 
Internal Rhai types and functions are volatile, so they may change from version to version and break code. 
Use internals only if the operating environment has absolutely no safety concerns – you’d
be surprised under how few scenarios this assumption holds.
One example of such an environment is a Rhai scripting Engine compiled to WASM where the
AST is further translated to include environment-specific modifications.
Don’t Panic Guarantee – Any Panic is a Bug

Rhai is designed to not bring down the host system, regardless of what a script may do to it. This is a central design goal – Rhai provides a Don’t Panic guarantee.
When using Rhai, any panic outside of APIs with explicitly documented panic conditions is considered a bug in Rhai and should be reported as such.
All these safe-guards can be turned off via the unchecked feature, which disables all safety
checks (even fatal ones).
This increases script evaluation performance somewhat, but very easy for a malicious script to bring down the host system.