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 default Content Security Policy ("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 applications safe from XSS attacks, even in the face of application coding errors. If these restrictions are too severe for an application, the CSP can be relaxed or disabled 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 reach application code. There is no risk that the application program will forget a decoding step or accidently miscode a decoding operation.
Cookies, query parameters, and POST parameters are silently discarded unless their names begin with a lower-case letter and contain only alphanumerics, underscores, and minus-signs. Hence, there is no risk that unusual parameter names can cause quoting problems or other vulnerabilities.
Reply text generated using the "wapp-subst" and "wapp-trim" commands automatically escapes 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 --lint 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 {...}.
The new (non-standard) SAME_ORIGIN variable is provided. This variable has a value of "1" or "0" depending on whether or not the current HTTP request comes from the same origin. Applications can use this information to enhance their own security precautions by refusing to provide sensitive information or perform sensitive actions if SAME_ORIGIN is not "1".
The --scgi mode only accepts SCGI requests from localhost. This prevents an attacker from sending an SCGI request directly to the script and bypassing the webserver in the event that the site firewall is misconfigured or omitted.
Though cookies, query parameters and POST parameters are accessed using the same mechanism as CGI variables, the CGI variable names use a disjoint namespace. (CGI variables are all upper-case and all others are lower-case.) Hence, it is not possible for a remote attacher to create a fake CGI variable or override the value of a CGI variable.
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.