<story><title>The Basics of Web Application Security</title><url>http://martinfowler.com/articles/web-security-basics.html</url></story><parent_chain></parent_chain><comment><author>CiPHPerCoder</author><text>I&amp;#x27;ve taken a different approach to explaining the basics of application security.&lt;p&gt;These are the things that are most likely to cause your application to be secure:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    1. Data being treated as code.
    2. Invalid (or missing) logic.
    3. Insecure operating environment. (e.g. outdated packages)
    4. Cryptography failures.
&lt;/code&gt;&lt;/pre&gt;
Data being treated as code covers the obvious things like SQL Injection and Cross-Site Scripting, and makes it easier to conceptualize the solution: Never mix the two. That&amp;#x27;s what prepared statements accomplish.&lt;p&gt;Invalid&amp;#x2F;missing logic is the realm of &amp;quot;missing access controls&amp;quot; and &amp;quot;confused deputy&amp;quot; problems. (This is also where I&amp;#x27;d place CSRF vulnerabilities.)&lt;p&gt;Insecure operating environment: A secure application on an insecure server is not secure. Patch your systems. Use HTTPS. WordPress can&amp;#x27;t save you from CVE-2012-1823. Apache can&amp;#x27;t save you from Shellshock.&lt;p&gt;Cryptography failures are their own category, where the phrase &amp;quot;padding oracle&amp;quot; is routinely uttered with a straight face, a single mistake can cripple your application, and comparing strings the normal way programmers compare strings is considered dangerous. The solution here for people who aren&amp;#x27;t interested in becoming an expert is to hire one. Or a team of them.&lt;p&gt;These descriptions are an attempt to address the fundamental problems with how insecure code is written, rather than to arm the reader with a checklist of specific instances of vulnerabilities they can check off.&lt;p&gt;I generally dislike checklists (OWASP 10, SANS 25).&lt;p&gt;How many people are well-armed against SQL Injection, but pass user data to PHP&amp;#x27;s unserialize() function with reckless abandon? This is a data-as-code issue.&lt;p&gt;How many people use str_shuffle() for password reset token generation? This is a cryptographic failure.&lt;p&gt;I wrote about this at length here: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;paragonie.com&amp;#x2F;blog&amp;#x2F;2015&amp;#x2F;08&amp;#x2F;gentle-introduction-application-security&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;paragonie.com&amp;#x2F;blog&amp;#x2F;2015&amp;#x2F;08&amp;#x2F;gentle-introduction-appli...&lt;/a&gt;&lt;p&gt;If anyone&amp;#x27;s interested, I also curate this reading list on Github: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;paragonie&amp;#x2F;awesome-appsec&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;paragonie&amp;#x2F;awesome-appsec&lt;/a&gt;</text></comment>
<story><title>The Basics of Web Application Security</title><url>http://martinfowler.com/articles/web-security-basics.html</url></story><parent_chain></parent_chain><comment><author>philjr</author><text>I say this with a lot of respect, but this seems pretty noddy for a Martin Fowler article. There&amp;#x27;s not a lot of meat here and I really don&amp;#x27;t consider myself an app sec expert :-)</text></comment>