@zackster I like the secure by default initiative, but I think you need to improve the ability to "whitelist" parts that still need it. The example solution to use

application action="update" secure: false

makes the entire application vulnerable with the hope that bad requests to other parts of the app don't happen at the same moment, but if your application was doing this often it would be left wide open. It would be better if the whitelist was scoped to the current request or file only, like a cfprocessingdirective or better yet block scope:

cfprocessingdirective xmlSecure=false {
   xml = xmlParse( trustedXml );
};

good question, i had the same concern, but it turns out not to be a problem each request has it's own snapshot of the application settings, while application scope variables are of course shared between requests, but you can always do conditional logic per request in the constructor of the application.cfc and it doesn't affect other requests a quick demo (use 5.4.2.11-SNAPSHOT) open the normal.cfm which runs a loop with sleep, dumping out

getApplicationSettings().xmlfeatures

while that's looping and dumping out the settings, then call the unsafe.cfm which changes the xmlfeatures to be unsafe nothing changes in the normal request

Thanks Zack, thats very interesting to learn that each request has a snapshot of the application settings so there isn't a race condition between concurrent requests