OWASP Security JDIs Project

Jump to: navigation, search


The aim of this project is to build up a libary of practical solutions to specific security problems.

Rather than give explanations of security issues and defensive techniques - something which is done by Cheat Sheets and HOWTOs - the JDIs will consist of detailed, explicit instructions addressing specific issues using specific technology.

Like recipes, a JDI may suit some tastes more than others and, again like recipes, there can be more than one JDI for the same problem.

The benefits will be

  • practical, if limited, solutions for developers without them first having to become an expert in the problem space - something which time often does not permit
  • usable code which can be a practical introduction to defensive technologies, such as ESAPI, AntiSamy, etc.

The Process

The project will

  1. endeavour to source a suitable solutions to specific, practical problems on request, and
  2. adopt solutions already developed by developers and/or security specialists which they would like to share.

Building the library

If you are looking for practical help on a specific topic please send your request in the first instance to Edwin Aldridge

If you wish to contribute a JDI, you can either email Edwin Aldridge with the information or you can edit the table below on this page, create a link directly in the table below and copy in the pro-forma as explained in the JDI Process page.

Note that new pages are created at the top level in the wiki and should be given the _JDI suffix for disambiguation purposes (as shown in the example wiki text).


JDI Status Tech Tag Issue Tag Strapline
New Recipe First Draft

The process of developing tried and tested instructions is as follow:

First Draft

JDIs should be started with a stub article linked from the table in the JDIs page using the pro-forma page as a template.

This will typically be based on the authors practical experience as a developer or security specialist.

At this stage, the JDI does not have to be complete or particularly well written, but it must provide the bones of a practical solution.


The project will endeavour to engage suitable subject matter experts to assist in completing and refining the first draft.

Once the first draft has been reviewed and revised and meets the requirements defined in the pro-forma page, the status may be changed to Drafted, at which point is is ready for review.


The JDI is then editorially reviewed by an independent reviewer and, after any necessary changes have been made, the status changed to Reviewed.

Amongst other things the review should ensure that

  • All sections are complete per the pro-forma
  • All links work


To progress to the final status of Tested it is necessary for an independent developer to use the JDI, to feedback, and for that feedback to be reviewed and incorporated.


The strapline is a phrase or short sentence explaining what this JDI is good for and what it is not good for.

Description: a (short) paragraph

Note that the page title should summarise the exploit and tech e.g. XSS prevention for JSP

Categories should also be placed here. They are formatted as
and should include tags for the technologies - both the host tech and the solution tech - and the vulnerability addressed.


Status Date Comments
First Draft contributed by ...


The intention of the security JDIs is to provide good solutions to real-life problems, rather than to provide general solutions for every circumstance.

The solution presented here should be secure - that is should leave no obvious exploits - however it may not cater for every circumstance. For this reason it is critical to follow the DO's and DON'T's below which define the limits of this particular solution.


Get the code

should include hyper links to code in binary and or source form should include dependencies


should include a link to explicit build instructions, or an extract, whichever is best may not always be necessary##


should include a link to detailed instructions on installation, or an extract, covering the following:

  1. how to modify config files (code snippets)
  2. where to put config files
  3. where to install classes and executables
  4. how to update paths and to what (code snippets)

Insert initialisation hooks

code snippets, locations and instructions for initialising code

Active code

snippets and locations for code which does the actual protection e.g. inline validation


Code snippets for testing protection

DO's and DON'T's

This section defines the limits of this particular security solution. If it is not possible to follow the DO's and DON'T's, then a different solution is required and the reader is referred to the Further Information section below.


  1. do X
  2. Do y


  1. A
  2. B

Further Information

Should include references and links, where available, to

  1. reference documentation on and products used
  2. the most relevant OWASP cheat sheet
  3. background material on the exploit(s) being defended against

First draft JDIs should include the {{Template:Stub}} markup