cancel
Showing results for 
Search instead for 
Did you mean: 

Secure reports should have a table of scan type and types of error found for each scan

0 Kudos

Secure reports should have a table of scan type and types of error found for each scan

Generally, once you find SQL Injection or Cross Site Scripting for a parameter, you don't need to know the hundreds of other exploit strings that also worked. The important information for the developers is that parameter x has Cross Site Scripting vulnerabilities or stack trace errors. So a table with 2 columns (scan type, issue type)  that had a row for every distinct combination of scan type (e.g. SQL injection) and issue type 'sensitive data returned' or 'stack trace' would be very useful. If some requests worked and some failed the developers can always look at the report for the specific strings, but generally if you are not validating or escaping input, the specific strings that caused the issue don't matter. 

Join the September Hub-bub to show off, learn and win