I solved the problem! I didn't came from CXF but from the Esapi filter (from OWASP) that I used to checked the http header. Ironic that a framework provided to improve security can be in fact source for unsecurity.
I think that the Esapi filter prevented CXF to parse a page containing the "<" char and redisplayed the service list page but using the url containing the XSS. And the CXF service page displayed the XSS in the HTML (I suppose it is because of the way CXF displays the value of the the "Endpoint address") So there is no security problem with CXF alone. But CXF + another filter can cause a problem because the SOAP service page uses the current url to write the "Endpoit address" value. Thanks for your help. Sami -- View this message in context: http://cxf.547215.n5.nabble.com/XSS-flaw-in-Available-SOAP-services-page-tp3398847p3400135.html Sent from the cxf-user mailing list archive at Nabble.com.
