Accepting the premise that XML usage is on rapid rise whether XmlSucks or not. Then we need to attain to InformationSecurity needs for taming this beast. There is a need to SecureXml, before XML based services can be released for use by external clients.

XmlSecurityAspects is a page for information sharing of Securing Xml based information transfer, including WebServices.

----
'''Security for the unstoppable SOAP based WebServices'''

For 2004 viewpoints that could be pessimistic towards security provisions for SimpleObjectAccessProtocol, refer a list of links in http://www.datapower.com/xmldev/xmlsecurity.html, within which BruceSchneier (Counterpane) view on SOAP has been relisted.

Another resource at http://tickle.unco.edu/cs395s04/emoore/security.html stated views of another expert, who claimed RestArchitecturalStyle implmentations can be implmented with better security.

''WebServicesSecurity as a service''

* From http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1026543,00.html and http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1005056,00.html

There exists a need to separate security services from business logic. Moreover, realitites of performance impact added by security services need to be factored in. This could mean limiting access to services to closed user groups. 

Soap and Xml said to be liable to cross-site scripting, cookie poisoning, and URL parameter changes. Denial of Service attacks have been observed in DTD external entities. In addition, tools for service discovery can be compromised and used to reveal vulnerabilities.

Protection schemes address security of the message header, the contents and the operations (services).
----
'''Resources'''

ExtremeOrchestration demand additional XmlSecurity provisions for WebServices. See "Beyond XML Firewalling" at http://xml.sys-con.com/read/45782_p.htm

----
CategorySecurity CategoryXml CategoryWebServices CategorySoa