GNgnkt·Aug 15, 2019
In SSL Pinning for ElectronOWASP
CheatSheetSeries
JavaScript2019–2025
OWASP / CheatSheetSeries
CheatSheetSeries
The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics.
14Distinct people
20Mentions
0Explicit recommenders
34KGitHub stars
What to know before exploring
What it is
The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics.
GitHub
Where it is used
No documented product use was verified in the last source check.
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, 5:05:26 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 year20 dated mentions
Observed mentions: 2019-03-03 04:56:18 UTC to 2025-12-22 12:06:57 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 |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 11 | 1 | 10 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 5 | 0 | 5 |
What Hacker News says
11 sourcesWorth mentioning that according to OWASP's latest recommendation #1 is considered as a first line of defense and #2 is considered more as a defense in depth technique (e.g. in addition to #1, not as a replacement): https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...)
The SameSite=Strict is also an honorable mention as an up and coming technique once all browsers support it.
In Developers don't understand CORSIndeed, this is the canonical way of avoiding CSRF (= XSRF) attacks. I intentionally only explained the header method because I didn't want to confuse readers with another concept, and because it's a really nice example to explain CORS.
https://github.com/OWASP/CheatSheetSeries/blob/master/cheats... is probably one of the best documents discussing this, including the drawbacks of the header method that I used (and warned against) in my example:
https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...
In Developers don't understand CORSYou can mark a cookie as samesite:
https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...
(as you mentioned, backwards compatibility requires that this is opt-in when the cookie is set, not opt-out)
In Developers don't understand CORSAnother option is to use a secure token (https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...) this is a PITA but frameworks like ASP.NET have this baked in so it's not really much of a hassle in practice.
In Developers don't understand CORSI gave this code a quick skim and it seems reasonably well thought out and I wish I'd seen it before I rolled my own at work. There are numerous security flaws that one can accidentally introduce with SAML and it seems you've avoided the obvious ones at the very least (i.e. not checking there's only a single assertion, etc).
Just in case you weren't aware of it, I found this page very helpful when developing mine: https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...
In Ask HN: A good way to support SSO in bootstrapped SaaS?OWASP Top 10 list. OWASP's website is kind of a mess in my opinion, but there are numerous external write-ups about the top vulnerability types.
https://www.cloudflare.com/learning/security/threats/owasp-t...
Also this github repo maintained by OWASP seems pretty exhaustive. The cheatsheets directory has a lot of different vulnerability classes.
https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...
This "Insecure Direct Object Reference" was recently combined into the "Broken Access Control" category with a few others.
In First American Financial Corp. Leaked Hundreds of Millions of Insurance RecordsThe most important step is to remember that data is a "toxic asset"[0], in that as long as you have it its a potential danger. Data deletion is a valid strategy for controlling risks, and as bdibs said in another top-level comment here, you can't have a data breach for data you never had in the first place.
Regarding [pseudo]anonymization, there are plenty of deanonymization attacks against various [pseudo]anonymization techniques, so always look into potential problems specific to the type of data you will be storing and [pseudo]anonymizing.
Something I would recommend to handle the data you do decide to keep; look up a HIPPA electronic compliance guide, and see what engineering practices have been settled on by folks who will get hit with enormous fines if there is a breach. Curiously, when there are consequences for breaches due to non
Read the rest
-compliance with data-handling best practices, companies get much better at doing the right thing. Industries where data-mishandling laws have teeth tend to have fewer breaches.
Although I do think there are lessons to be learned for virtually everybody from HIPPA compliance guidelines, the approach you will end up using to protect your data will not be a one-size fits all approach; you will need to consider the architecture of your system, the kinds of data you need to keep, what you'll be using it for, whether you will access it regularly, etc.
A good place to start looking is here[1]. It's got a huge number of short "cheat sheet" like guides that cover a narrow topic relating to security. Some ones you might want to check out: password storage[2], authentication[3], attack surface analysis[4], SQL-injection prevention[5], cryptographic data storage[6]. Find guides related to your data and what you want to do with it, then read up, following some of the recommended other links in each cheat sheet.
[0] https://www.schneier.com/essays/archives/2016/03/data_is_a_t...
[1] https://github.com/OWASP/CheatSheetSeries
[2] https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...
[3] https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...
[4] https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...
[5] https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...
[6] https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...
Disclaimer: I am NOT a security expert, just someone with a hobbyist's interest in security. All opinions expressed in this comment are my own, and are not necessarily reflective of the security community at large. I encourage anyone reading this to do their own review of security best practices, the opinions of security researchers, and the technical literature on security.
In case you are still interested in reading about the security aspect of logging, there is the OWASP Logging Cheat Sheet dedicated to this:
https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...
In Application-Level Logging Best PracticesI found this, describing his specialty:
"Lopez specializes in the identification of Insecure Direct Object Reference flaws also known as IDOR vulnerabilities."
Then this, explaining IDOR: https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...
It certainly sounds like the sort of thing you could automate to a pretty big scale.
In Teen Becomes First Hacker to Earn $1M Through Bug Bounties