OWASP
New CS proposal: Security Definitions
I find that even senior developers struggle with some security terminology. Encoding vs escaping vs serialization? Signatures vs encryption? Etc.
I suggest we build a cheatsheet that goes over security terminology that is critical to understanding other projects like the ASVS standard. It assumes developers have a basic security understanding.
I think this is a great idea as well! Just to double check, are there any other OWASP projects that already have something like this? I know theres the CNCF Glossary which may be a good reference for this effort.
Hi @jmanico,
This cheatsheet idea sounds great — I can help compile and organize the glossary, referencing OWASP and CNCF sources to keep it consistent. Could you please assign me this issue so I can start drafting?
Thanks!
This cheatsheet idea sounds great — I can help compile and organize the glossary, referencing OWASP and CNCF sources to keep it consistent. Could you please assign me this issue so I can start drafting?
Done!
@jmanico I have some suggestions.
I find that even senior developers struggle with some security terminology.
I agree. I think that providing only simple terminology definitions may not fully solve the problem. Developers can already get basic definitions from sources like ChatGPT by asking ex. “what is encoding”., But by asking a simple question they may not get below information: I believe this below information would make this cheatsheet uniquely valuable is adding context around each term:
- Why the terminology is crucial in security.
- How misunderstandings or incorrect usage can lead to vulnerabilities.
- Real-world examples or common vulnerabilities reported due to misuse.
- Where developers should focus in their projects to apply the concept correctly.
- Practical use cases and best practices.
This is just a quick thought, if this is not align with your expectation then please ignore :).
I think this is a great idea as well! Just to double check, are there any other OWASP projects that already have something like this? I know theres the CNCF Glossary which may be a good reference for this effort.
Not sure if there are other OWASP projects doing this, but speaking from experience (I attempted to do this first for a security class I taught and then later with an AppSec team at a former company until it became a maintenance headache), there are other good public security glossaries out there. I know that NSA has one and I think NIST does as well. And IEEE has one, but it's not limited to just security terminology.
My conclusion is it was just easier to link to someone else's definition than for our team of 5-7 AppSec engineer's to maintain our own. Also, if you link to something like the NSA glossary (if it's still a thing), very few are going to argue with the definition. If we write our own definitions, that's not going to be the case. Just sayin'.
Thanks for the feedback! I agree with @ajayojha - adding context, real-world examples, and best practices for each term will make this cheatsheet more practical.
To address @kwwall’s point, we can use authoritative sources like OWASP, CNCF, NSA, and NIST for core definitions, then enrich them with examples and guidance. This keeps credibility while adding unique value.
I can start drafting a template for each term to make it easy to expand and maintain. Thoughts?
To address @kwwall’s point, we can use authoritative sources like OWASP, CNCF, NSA, and NIST for core definitions, then enrich them with examples and guidance. This keeps credibility while adding unique value.
I could get behind the idea if the plan is to going beyond just definitions and plan to enrich them with examples, guidance, diagrams, etc. But if all we were going to do is to just link to a mere definition it's a lot less work to just link to some other reputable 3rd party definition. rather than trying to maintain you own glossary. Been there, done that, and it's lot of work with not much benefit.
Thanks for the clarification, @kwwall!
I agree with you - just repeating definitions from other sources would add little value and become hard to maintain. What I had in mind is more of a hybrid approach:
Link to trusted sources (OWASP, CNCF, NSA, NIST, etc.) for the baseline definition.
Add context around why the term matters in security and how misuse can lead to vulnerabilities.
Provide real-world examples, common pitfalls, and practical best practices.
Where useful, include diagrams or short code snippets to make the concept easier to understand.
This way we get the benefit of authoritative definitions without reinventing the wheel, while also offering developers something they can’t get from just a glossary link.
I can draft a template for one or two terms (like Encoding vs Escaping, Encryption vs Signature) to show what the enriched format might look like. Does that sound like a good direction?
I like this direction. The definition of these items is often not enough for developers to take action...
Thanks @jmanico!
I’ll start by drafting a sample entry for Encoding vs Escaping using the enriched format we discussed:
Baseline definition (linked to OWASP / CNCF / NSA / NIST).
Why the term matters in security (risks of misunderstanding).
Real-world examples & common vulnerabilities.
Best practices / how to apply correctly.
Optional diagram or snippet for clarity.
To make the structure clearer, I can also draft a contrasting example like Encryption vs Signature so we can validate the format across different categories. Once these are ready, the team can review and adjust the template before we scale it to more terms.
This is fantastic. I suggest several small PR's instead of one big one, so we can make our changes together one step at a time. :)
Thanks @jmanico!
That makes sense, I’ll start with a small PR for one sample entry (Encoding vs Escaping), so we can refine the structure together. After that, I can follow up with another small PR for Encryption vs Signature to validate the format across categories. Once we’re happy with the template, I’ll proceed gradually with more terms in separate PRs.
This way we keep it iterative and easy to review.