I took a quick look at some source files, here's one thing I found:
> commandes.php: > > htmlspecialchars(stripslashes(trim($_POST["cmd"])))
It's generally bad practice to encode for HTML before you save to the database. You might want to use the data in a non-HTML context but more important you are making it harder to audit whether you haven't 'missed a spot'.
Also an easier way to prevent SQL injection is to use https://secure.php.net/manual/en/pdo.prepared-statements.php, this will leave your input data as it is and leave the hard work of encoding data for transport up to the database driver.
Then before you 'echo' to HTML, use htmlspecialchars there.
For more information: https://stackoverflow.com/questions/110575/do-htmlspecialchars-and-mysql-real-escape-string-keep-my-php-code-safe-from-inje
Thank you! Generally I'm a fan of Paragon's work, but I'm also a Drupal and Wordpress dev (who's dabled in Joomla as well) and these last two airship pieces really haven't done much for me.
The biggest issue I'm having with their framing is that it feels no better/different than the thousands of "My CMS is better than yours" posts across the web. It's like arguing hammers are better than table saws because they are better at pounding things in.
From the Drupal side, I think Drupal does take security seriously (more so than any of the other CMS's I work with see Wordfence v 404 to 403 plugin ), and adding patches that cover these concerns is just a matter of doing the work (maybe aside from auto-updates?).
With that said - if you compare the quantity of work necessary to write and maintain a full CMS, with the time necessary to write the patches to address these issues and push them through the Drupal community, the math doesn't make sense for me.
On balance, it's great that airship is out there, and I'm disagree with people who are hating on it. If I need to look a good secure approach to implementing a feature, it's a good place I'll look. That said, it's hard to see a time in the near future when selling airship to a client will be a viable option.
https://www.drupal.org/drupal-security-team/security-risk-levels-defined
​
Here is the full explanation of what Drupal Security levels are and what they mean, there are 5 levels of criticality based on an existing threat scoring standard.