<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 23 Aug 2018, at 08:46, Johan Brichau <<a href="mailto:johan@inceptive.be" class="">johan@inceptive.be</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Seaside does help the developer a little to prevent CSRF attacks: all output is encoded per standard. If you store user input and render that directly on your page, you do not have to care if a user would enter malicious scripts to make a CSRF attack. Per default, standard Seaside rendering will encode the output to html text. There is one place in Seaside where this is not done: rendering of title attributes (ssshhhht!! :-). Still want to fix this… but it’s rather annoying in the current code as far as I remember.</span></div></blockquote></div><br class=""><div class="">oups, I was reading ‘cross-site-scripting-attack’ instead of ‘cross-site-request-forgery’… </div><div class="">But that’s part of Seaside security as well :)</div><div class=""><br class=""></div><div class="">Johan</div></body></html>