http://grails.org/doc/latest/guide/security.html
http://grails.org/doc/latest/guide/security.html
I also saw that there is an encodeAsHTML method that I can call to encode on the way back down to the client. Wouldn t I want to do this before it went into the database so that I only have to encode once? Thanks!
User Input
The idea of "sanitizing your inputs" (or pre-encoding or pre-escaping) your content is a terrible one. It does not actually protect you when you really need it, and leads to all sorts of design headaches. Even PHP finally dumped the technique.
It s always better to handle the data via proper APIs correctly, which eliminates the risk. For example, SQL injections is absolutely eliminated using prepared statements or statements with placeholders for the content. This technique has been around for a very long time (as long as I ve using Java & SQL).
Grails (GORM) automatically handles encoding any content that is saved via the objects, including setting a single property, creating a new object and saving it, or setting properties via obj.properties = params or something similar.
As long as you are using GORM, there is no risk of SQL injection.
Content Storage
Also, it s generally considered incorrect to store the already-encoded information in the database, as that encoding would only be correct for a given display type (such as HTML). If you instead wanted to render it using JSON, the HTML encoding is incorrect. XML is also slightly different, and there are times when you might prefer plain text, too.
http://grails.org/plugin/cache
http://grails.org/plugin/cache
http://en.wikipedia.org/wiki/Cross-site_scripting
http://en.wikipedia.org/wiki/Cross-site_scripting
http://grails.org/doc/latest/guide/conf.html#builtInOptions
http://grails.org/doc/latest/guide/conf.html#builtInOptions
grails.views.default.codec = html
This will only affect GSPs, and only content echoed using dollar-sign syntax (${foo}). This gives you the flexibility of overriding this behavior using tags (the recommended way) or the <%= %> syntax for one-off situations. It should, however, provide a decent catch to prevent XSS attacks in general.
Performance Considerations
One final note: the concern about encoding the content as HTML being a performance issue would be considered premature optimization . Chances are extremely high that any performance bottlenecks would be somewhere else, and not in the encoding of the content. Build your application first — using a good design — and optimize later after you can benchmark and analyze the running application.
http://stackoverflow.com/questions/11486894/grails-security-encoding-by-default