Automated Security Analyser for ASP.NET Websites

Website secuity scorecard

Website security scorecards are an easy way to self-assess risks in websites without engaging in potentially malicious activities. The scorecard helps you identify common risks in a way which they can then be shared complete with explanations as to the nature of the risk. This is useful for both assesing risks within your own sites or responsibly disclosing those within others. No logging of any kind is done, the scorecard below creates a uniqe URL containing the assessment as you fill it out, just share the address once you're done.

1) Enter the address of the website you're scoring

The URL will only ever appear in your scorecard report, it is not stored anywhere.

Scorecard form

2) Assess the website risks

Give each risk a pass or a fail based on your own self-assessment. You can click the button again to deselect it. A risk without a rating won't appear on the scorecard report.

Website security scorecard

Lack of transport layer protection for sensitive data

HTTPS protects data from being read or manipulated whilst in transit. A lack of HTTPS when either sending or receiving sensitive data (anything that you wouldn't want made public) leaves users at risk of their data being intercepted by a man in the middle. More reading

Loading login forms over an insecure channel

Login forms must be loaded over HTTPS. When they are loaded over an insecure connection they are left vulnerable to being manipulated by a man in the middle who could change the page in order to harvest credentials. More reading

Secure cookies

Cookies that contain sensitive data must be flagged as "secure". Particularly when data such as auth tokens are stored in cookies, they must be protected in transit to prevent risks such as session hijacking. More reading

Mixed mode HTTP and HTTPS

Mixed mode HTTPS occurs when the page is loaded over a secure connection but then embeds other content loaded over an insecure connection. The risk is that the other content may be intercepted and manipulated hence changing the behaviour of the page. More reading

Cross Site Scripting (XSS)

XSS risks occur when input data is not properly sanitised and responses do not correctly output encode untrusted data. The consequences of XSS can range from session hijacking to self-propagating worms. More reading

Password reminders via email

Passwords must never be sent via email during a reset process. Email poses risks in both transit and storage and is never a suitable means for websites to send persistent credentials such as passwords. More reading

Insecure password storage

Passwords must be stored securely with an appropriate cryptographic hash function. Storage in plain text, using encryption or weak hashing algorithms such as a single round of salted SHA1 are weak and leaves credentials vulnerable. More reading

Poor password entropy rules

Passwords are strongest when they are long and random. Artificial constraints on passwords such as low lengths, the exclusion of certain characters or confinement to a subset of the full character set (such as only digits) leaves passwords more vulnerable. More reading

Denial of service via password reset

Password reset facilities should not lock out an account. Immediately invalidating the existing credentials allows an attacker to easily lock someone out of their own account thus denying them access to the service. More reading

HTTP only cookies

Cookies not required to be read by client script must be marked as "HttpOnly". Not doing so leaves them at risk of attack through vectors such as XSS which may then lead to attacks such as session hijacking. More reading

Internal error messages

Internal errors within the application should not leak implementation information. Error messages often contain debugging information which can provide an attacker with an advantage when probing for further vulnerabilities within the application. More reading

Path disclosure via robots.txt

The robots.txt file may leak information about the structure of the website that could be used to an attacker's advantage. Don't include paths you do not want to be made public knowledge and always implement proper access controls. More reading

Sensitive data leakage via HTML source

No data that could be used to an attacker's advantage should be inadvertently disclosed in the HTML source. This includes comments in the markup and any other information that could leveraged in an attack against the site. More reading

Parameter tampering

Parameters passed to the application should be considered untrusted data. Manipulation of the parameters including query string, form data and HTTP headers should not cause the application to behave in an insecure fashion. More reading

Clickjacking and the X-Frame-Options header

It should not be possible to embed the website inside the frame on another website unless explicitly required. Use an X-Frame-Options header to describe the allowable use scenario and limit the risk of a clickjacking attack. More reading

Cross Site Request Forgery (CSRF)

Use anti-forgery tokens on all authenticated actions which change the application state. An attacker should not be able to impact a change or cause an adverse result simply by tricking a user's browser into issuing an HTTP request. More reading

3) Share your scorecard

The URL below contains all the scorecard data you've just configured. You can click it at any time to see how your scorecard will look in a new window. Share this to provide a read only version of your assessment.

No data yet