CICiPHPerCoder·Jun 3, 2016
https://github.com/paragonie/awesome-appsec
We've been trying to maintain an up-to-date list.
In Ask HN: Which are the best books for security conscious full stack web devs?paragonie
awesome-appsec
PHP2015–2020
paragonie / awesome-appsec
awesome-appsec
A curated list of resources for learning about application security
8Distinct people
22Mentions
0Explicit recommenders
7.1KGitHub stars
What to know before exploring
What it is
A curated list of resources for learning about application security
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 4:00:59 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year22 dated mentions
Observed mentions: 2015-05-02 14:44:27 UTC to 2020-07-23 05:45:13 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 14 | 4 | 10 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
7 sourcesYikes. Sorry about that, something went wrong with my init scripts and our server rebooted earlier. It's up again and I'm looking into the problem.
Our blog posts in particular:
https://paragonie.com/blog/category/security-engineering
A reading list we maintain for application security (and some crypto stuff):
https://github.com/paragonie/awesome-appsec
In Keeping secrecy the exception, not the ruleThis is an amazing resource! https://github.com/paragonie/awesome-appsec
In The Basics of Web Application SecurityI've taken a different approach to explaining the basics of application security.
These are the things that are most likely to cause your application to be secure:
1. Data being treated as code.
2. Invalid (or missing) logic.
3. Insecure operating environment. (e.g. outdated packages)
4. Cryptography failures.
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's what prepared statements accomplish.
Invalid/missing logic is the realm of "missing access controls" and "confused deputy" problems. (This is also where I'd place CSRF vulnerabilities.)
Insecure operating environment: A secure application on an insecure server is not secure. Patch your systems. Use HTTPS. WordPress can't save you from CVE-2012-
Read the rest
1823. Apache can't save you from Shellshock.
Cryptography failures are their own category, where the phrase "padding oracle" 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't interested in becoming an expert is to hire one. Or a team of them.
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.
I generally dislike checklists (OWASP 10, SANS 25).
How many people are well-armed against SQL Injection, but pass user data to PHP's unserialize() function with reckless abandon? This is a data-as-code issue.
How many people use str_shuffle() for password reset token generation? This is a cryptographic failure.
I wrote about this at length here: https://paragonie.com/blog/2015/08/gentle-introduction-appli...
If anyone's interested, I also curate this reading list on Github: https://github.com/paragonie/awesome-appsec
Awesome AppSec – a curated list of resources for learning application security
3 points · Open discussionThe proper fixes for common web application vulnerabilities are as follows:
Session Hijacking/Fixation/etc.: Use TLS.
SQL Injection: Prepared statements that AREN'T emulated; PHP's defaults are bad here.
EDIT: If you're writing in another language, make sure it's not providing string escaping masquerading as prepared statements, but actual prepared statements. (My earlier comment was too broad; some forms of emulated prepared statements might be OK, but PHP's is dangerous.)
Cross-Site Scripting: Context-aware escaping (templating libraries) + Security Headers
Cross-Site Request Forgery: CSRF tokens
Password storage: bcrypt, scrypt, PBKDF2-SHA2, Argon2
Encryption, Digital Signatures, Authenticated Key Exchanges, etc.: Hire an expert, don't do it yourself based on the advice contained within HN comments.
File Inclusion / Directory Traversal
Read the rest
: Don't write your applications in a dumb way that makes these vulnerabilities possible. But if you must, use something like realpath() with a sanity check based on the expected parent directory (in PHP).
XML External Entities: Make sure you disable the entity loader:
libxml_disable_entity_loader(true);
PHP Object Injection in PHP 5: don't ever pass user input to unserialize(); use json_decode() instead.
PHP Object Injection in PHP 7: either disable object loading or whitelist the allowed types; i.e. unserialize($var, false); or unserialize($var, ['DateTime']);
These are just some of the common problems I frequently find, of course. There are more basic ways to mess up an application ("not even checking that you're authenticated" being at the top of that list).
https://paragonie.com/blog/2015/08/gentle-introduction-appli...
Further reading and resources:
* https://securityheaders.io
* https://github.com/paragonie/awesome-appsec
And if anyone wants their code reviewed: https://paragonie.com/services