I do not know, whether GNU Artanis makes use of SXML all the way, but I think it is very likely, since SXML is in GNU Guile's standard library.
(All the other nodes are symbols with potentially subtrees in them, which are also symbols with potentially more subtress in them.)
If you put your user input into one such node as a value of that node, lets say a paragraph tag <p>, then SXML sees the user input as it is, a string. It will make sure, that when it turns the tree into HTML, that string remains merely a string, by escaping things, so that for example when your string is <evil-tag-with attrs="bla"> this is exactly what will be seen as text inside your paragraph text, and not be interpreted.
Basically, SXML will render it like: "Oh, you want some string to be inside your p tag? Sure, can do ... This is what you wanted to be displayed to the user ... You didn't want to run that, did you? Nahh, because then you wouldn't have passed it in the SXML as text content of a p tag."
So I think the answer to your question is "Yes.".
But of course this only applies when you use sxml. Artanis apparently can also use plain strings or templates as responses, in which case you will have to take care of safely encoding things too.
Rather, things are structured, so it's more like a in-memory representation of XML. It doesn't need to be serialised, only deserialised into XML's text syntax. In which case, each piece knows how it needs to be encoded.
'(h1 (@ (id "greeting")) "Hi, there")
Its just lists of Symbol types, and string or other type values. <script>alert("yoov bin acked")</script>
And that's my username, if it's naively inserted inside some HTML it'll look like HTML to a browser.So I was wondering if this framework auto-HTML-escapes strings inserted into places where text can go.
CSRF is cross site request forgery, f.ex. creating a POST form on a hostile site that targets a POST processing endpoint in on site with data that the user didn't want to supply, but whose login cookie would authorize the request at the target.
Many frameworks inject an per-user "authentication" cookie in form's that is validated upon request, this way an attacker cannot trick the users browser to submit data since they don't have the correct CSRF-cookie.
https://owasp.org/www-community/attacks/csrf
https://developer.mozilla.org/en-US/docs/Web/Security/Attack...
But, specifying your own headers is easy, and we had it in a macro we used for our routes.
So instead, to rip from the manual:
(response-emit
body
#:status 200
#:headers '(
(Content-Type . application/json)
(X-Frame-Options . DENY)
)
#:mtime (current-time))Many frameworks inject an per-user "authentication" cookie in form's that is validated upon request, this way an attacker cannot trick the users browser to submit data since they don't have the correct cookie.
https://owasp.org/www-community/attacks/csrf
https://developer.mozilla.org/en-US/docs/Web/Security/Attack...
And the standard ways of doing that, generating single use tokens, will work the way they usually do.
As I said... I didn't use cookies. Which means none of what you listed applied in the first place. Logins were entirely ephemeral and died after a single session ended - as pains were taken to ensure anonymity.