LiquidJS provides DoS-oriented limits (parseLimit, renderLimit, memoryLimit) to reduce risk. This page explains what each limit protects, and the security boundary you should assume in production.
LiquidJS provides DoS-oriented limits (parseLimit, renderLimit, memoryLimit) to reduce risk. This page summarizes those limits, ownPropertyOnly, custom Drop usage, and the security boundary to assume in production.
Security boundary
The built-in limits are cooperative safeguards, not strict runtime isolation.
- They do not equal process RSS/heap usage. @@ -126,6 +126,8 @@ {% endfor %}
- Prefer curated templates or a restricted template subset. @@ -136,7 +138,7 @@
As JavaScript uses GC to manage memory, memoryLimit may not reflect the actual memory footprint.
ownPropertyOnly and scope data
With ownPropertyOnly true, plain scope objects only expose own properties (no inherited / Object.prototype keys). Default false follows normal JS property access. Use true for untrusted or polluted objects; add strictVariables if missing paths should error. Override per render via RenderOptions. This is a read policy for scope data—not a sandbox for filters, tags, or your code.
Custom Drop classes
Drop values are not restricted the same way: LiquidJS still reads the prototype chain and may call liquidMethodMissing. You control what a drop exposes; narrow APIs and never feed unsafe data into drops unless the class is built for template access. ownPropertyOnly alone does not harden custom drops—audit them like any privileged code.
Online service guidance
If you run an online service, avoid rendering fully user-defined templates whenever possible.
Deprecated
will be removed. In tags use
-this.parserinstead