They struck me as both unrealistic considering the clojure community and a little too much "find the silver bullet" for my tastes. That said, I understand why a security focused person would want this and if my role was to be concerned about these things I would probably push in that direction as well. When taking a larger view however, this is a poor tradeoff IMO.

"I wouldn't want to give up the approach of composing a bunch of libraries to build concise, easy-to-reason-about web apps in Clojure--I think it helps with security in and of itself--but the community could really benefit from having more libraries which nail these things down and help developers build web apps more safely, with less work."

You nailed it, well said. I want a checklist and good libraries, not a framework that promises to handle things for you but quietly leaves a big hole open in that one part where you had to work around the framework to solve your problem (there is always at least one isn't there?).

You just can't avoid understanding these common attacks and how to mitigate them, at least at a surface level. You have to at least know where to apply the appropriate techniques, the implementation of that technique is left up to a well documented library written by experts.

"That said, I don't think it's all bad: you can build high quality, secure web apps in Clojure, it just requires you to really pay attention to security. And we should be doing that anyways, right?"

Not only should you be doing that, but if you aren't designing with security in mind then you are doing it wrong IMHO, "secure by default" framework or not. Either the people configuring the framework or the people writing the layers at the edges need to understand web security.

All that said, I understand the push in this direction. If you have a large team of junior devs then you want to limit their power. It's just not an approach that fits very well with Clojure. It's like Rich Hickey's attitude towards unbounded queues: there is no support for them, because you must be aware of this issue and hiding it causes bugs. There, now I've invoked Rich Hickey to justify my anti-framework bias ... so I must be right.

He has a point. Is one really that much better than another? Also, shouldn't it be possible to come up with a single library to do HTML escaping that has the suitably paranoid defaults, which is then used by all the templating languages? Is one templating language's code for that going to be so much revolutionarily better than another's?

"everyone use a (heavy, highly opinionated) framework", etc.

My understanding is that he pointed that out as a solution other environments have taken (Rails) but that there was also value in the composable way of doing things in Clojure. His actual position, I understood as, "there must be some way of unifying this for Clojure."

It would be business suicide to demand all your web designers learn clojure edn syntax in order to write out HTML in hiccup. They have work to do and they are experts with their existing tools, including quite complex IDEs.

If the html is being generated programmatically by clojure devs then hiccup type formats are extremely efficient. String building techniques suck worse for HTML than they do for SQL.

By far the most common types of template languages are the placeholder type. People love them. I hate them, moustache/ctemplate style templates are an excellent attempt to remove logic from them but why not just go all the way towards an enlive style if you recognize this benefit? I'm not the right person to defend them but the general argument is that designers can learn the crippled DSL easily and they can implement the simple parts of the template logic themselves. Moustache style templates are also useful if you are templating something like plain text that doesn't have structure.

And yes, I absolutely think that the single library to do HTML escaping with extremely paranoid defaults is the right solution. But a security person is going to be nervous that developers will not use it every place they should and unless I'm remembering incorrectly the request was for this to be integrated into the templating library to remove that error path. I'm not even sure how that could work properly outside of the placeholder paradigm (it has been done well in Haskell using types to track escaped/unescaped segments if memory serves).

In regards to frameworks: I think you are right about this position, I just really very much disagree that there "must be some way of unifying this in clojure" outside of an opinionated framework. The problem is the lack of ability to enforce a specific dataflow / data transformations that can be audited for security and generally applied. Enforcing a specific dataflow is the definition of a framework IMHO.

I fully agree with his push for more and better web security related libraries (I'm tired of doing these things myself but don't have the security expertise to create general solutions that anyone should trust) but some of it struck me as "if we just limit the expressive power of clojure for web development we can mitigate a large swath of security issues". He's absolutely right, but I have found that tradeoff to be a very poor one to choose outside of the simplest of CRUD apps.

Right, that's done in Hamlet (which was developed for Yesod, but is its own library).

http://hackage.haskell.org/package/hamlet

As a community we should highlight libraries with a focus on security as well. I think key is focusing on making this a community consideration early and not falling into the same pit of issues as other popular languages/frameworks which shall remain nameless for the purpose of this comment.