API Security Checklist for developers
There&#x27;s some OK stuff here, but the list on the whole isn&#x27;t very coherent. If this is a guide specifically for &quot;APIs&quot; that are driven almost entirely from browser Javascript SPA&#x27;s, it makes sense. Otherwise, a lot of these recommendations are a little weak; for instance, most of the HTTP option headers this list recommends won&#x27;t be honored by typical HTTP clients.<p>Further, the list succumbs to the cardinal sin of software security advice: &quot;validate input so you don&#x27;t have X, Y, and Z vulnerabilities&quot;. Simply describing X, Y, and Z vulnerabilities provides the same level of advice for developers (that is to say: not much). What developers really need is advice about how to structure their programs to foreclose on the possibility of having those bugs. For instance: rather than sprinkling authentication checks on every endpoint, have the handlers of all endpoints inherit from a base class that performs the check automatically. Stuff like that.<p>Finally: don&#x27;t use JWT. JWT terrifies me, and it terrifies all the crypto engineers I know. As a security standard, it is a series of own-goals foreseeable even 10 years ago based on the history of crypto standard vulnerabilities. Almost every application I&#x27;ve seen that uses JWT would be better off with simple bearer tokens.<p>JWT might be the one case in all of practical computing where you might be better off rolling your own crypto token standard than adopting the existing standard.