I ask because I'm currently using jsonp to access yacysearch.json from clients of peer-search.net, but I'm concerned that if somebody modified a yacy peer to return malicious javascript from yacysearch.json, they could deface peer-search.net or inject fake results.

So, instead I would like to make a CORS request to yacysearch.rss (no json injection possibility), but I can't do that unless the header mentioned above is set.

I don't understand this completely. How can somebody inject malicious code in yacysearch.json; the data that is taken from the servlet is only interpreted as data and never executed.Wouldn't "Access-Control-Allow-Origin=*" cause another security leak? It enables the peer to read content not only from the same server where the code came from; but this is the intention to ensure security. CORS shows examples where it is useful for javascript code to read from different sources but this is not the thing we want to do _inside_ a YaCy peer. Peer-Search may want this functionality but this can be done using a "Access-Control-Allow-Origin=*" setting on _your_ server.

Currently when a visitor comes to peer-search.net, their browser makes requests to lots of yacy peers - it loads script from yacysearch.json. (check out how jsonp / cross-domain json works - a script tag is inserted into the client dom). This means that if a malicious user wanted to, they could modify yacysearch.json to deface peer-search.net because yacysearch.json actually runs in the client jvm due to the way jsonp works... when you say "the data that is taken from the servlet is only interpreted as data and never executed".... that is not correct. (I have verified this with an injection script that hides the menu on peer-search.net instead of supplying search results)).

With modern browsers that support CORS, the http header "Access-Control-Allow-Origin" must be returned by the server that hosts the remote resource being requested by a client script. If that header is present and matches the requesting domain, only then may a client script load the resource with an xmlhttprequest object (this is not a security threat to yacy, it just makes yacysearch.rss more available). The header must be returned by the server that owns the resource (in this case, each yacy peer). Setting that header on my server would make no difference as it's not my server that hosts yacysearch.rss. If you wanted to be cautious, instead of "Access-Control-Allow-Origin=*", you could return "Access-Control-Allow-Origin=www.peer-search.net" but then nobody else would be able to load yacysearch.rss from a client web page.

JSONP requires that you trust the server that you're loading the script file from (as that script runs in the client dom) - and unfortunately, in the case of a malicious yacy peer, that would not be the case. This is why I want to move to using yacysearch.RSS instead of json (for XML, your statement would be true - an altered peer would only be able to return a set of altered results and would not be able to inject any code because the results would indeed just be treated as data), but I need that header to be present before I can do that.

I created a patch for SVN 7233 that includes the CORS origin header for yacysearch.rss here: CORS-SVN7233.patch

Since this adds an additional if statement with String comparison to each internal file request I would like to let this one be reviewed by someone first before I check it in. It might be a lot smarter to use userProperties from the yacysearch.java servlet to add this line to the header.

In line 1285 of HTTPDaemon.java there seems to be a spot where this was once prepared but not implemented because of possible problems with intersecting user header properties://Append user properties to the main String//TODO: Should we check for user properites. What if they intersect properties that are already in header?

Well, it took a while until I understood everything in context of this patch request. The main reason that CORS should be supported is that JSONP can be unsafe. Therefore I now added the CORS functionality for rss output in yacysearch.rss in SVN 7288I used some of Copros patch code, but did it a little bit differently in such a way that every servlet can request the CORS header if necessary.