Artifact 5776ee6a488e135868d578cbc8e3188279b658e969e680f2db19afddeffd0537:
- File docs/security.md — part of check-in [985de3d884] at 2018-02-02 14:51:32 on branch trunk — Updates to the documentation. (user: drh size: 2828)
Security Considerations
Wapp strives for security by default. Applications can disable security features on an as-needed basis, but the default setting for security features is always "on".
Security features in Wapp include the following:
The default Content Security Policy of "CSP" for all Wapp applications is default_src 'self'. In that mode, resources must all be loaded from the same origin, the use of eval() and similar commands in javascript is prohibited, and no in-line javascript or CSS is allowed. These limitations help keep application safe from XSS attacks attacks, even in the face of application coding errors. If these restrictions are too severe for an application, the CSP can be relaxed using the "wapp-content-security-policy" command.
Access to GET query parameters and POST parameters is prohibited unless the origin of the request is the application itself, as determined by the Referrer field in the HTTP header. This feature helps to prevent Cross-site Request Forgery attacks. The "wapp-allow-xorigin-params" command can be used to disable this protection on a case-by-case basis.
Cookies, query parameters, and POST parameters are automatically decoded before they ever reach application code. There is no risk that the application program will forget a decoding step or accidently miscode a decoding operation.
Reply text generated using the "wapp-subst" and "wapp-trim" commands automatically escape generated text so that it is safe for inclusion within HTML, within a javascript or JSON string literal, as a URL, or as the value of a query parameter. As long as the application programmer is careful to always use "wapp-subst" and/or "wapp-trim" to generate replies, there is little risk of injection attacks.
If the application is launched on a command-line with the --trim option, then instead of running the application, Wapp scans the application code looking for constructs that are unsafe. Unsafe constructs include things such as using "wapp-subst" with an argument that is not contained within {...}.
Part of what makes Wapp easy to use is that it helps free application developers from the worry of accidently introducing security vulnerabilities via programming errors. Of course, no framework is fool-proof. Developers still must be aware of security. Wapp does not prevent every error, but it does help make writing a secure application easier and less stressful.