View source for IG/W3C spec review/Security Guidelines

== Draft Security Guidelines for chairs and editors ==


==== Some good practices ====
- Security considerations have to be filled in any W3C recommendation. It covers both developer and browser implementers perspectives. 

- Chair and editors may identify one security champion in the WG, to support security discussions or be a relay for security experts.

- The W3C Web Security IG may be the good place to direct security related questions, as it gathers some security experts.

- Chairs and editors could also get inspiration from others Security Considerations from other spec (compilation on going in W3C Web Security IG)

==== Ressources ====
Read the security guidelines from IETF [https://tools.ietf.org/html/rfc3552]. 

Read the privacy guidelines, as privacy implies sometimes to include some security features : [https://tools.ietf.org/html/rfc6973 IETF guideline] and [http://www.w3.org/TR/2012/NOTE-app-privacy-bp-20120703/ W3C note]

Make sure you are aware of the risks highlighted by OWASP guidelines - specially the top 10 [https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_2013]

==== Some questions you should raise when designing your API ====
- Think how the technology you are developing is actually interfering with other W3C/IETF technologies : CORS, CSP, usage of HTTPS, trusted interface, ...

-Play a 'malware user scenario' when reviewing your spec (e.g. what if the wrong application gets the handler on sensitive assets) 

-Challenge the possible implementation choices related to sensitive information management, and make sure risks are highlighted in the spec for the implementers and developers 

-ask the following question: would some security assets be better protected by having an interaction between the user and the UA (and then include this into the spec warning about it)