Apart from the problem of trust and how a Semantic Web agent might rate new information it receives, there are some quite concrete security concerns to be aware of when engineering a Semantic Web application.
Always be careful when you allow for external data to be loaded into your RDF store. Sure this applies everywhere, but people might not be as aware of it for RDF stores and so far I haven't seen any discussion of it.
It might always be a good idea to keep the external data you load separate from the data especially created for the store. You could put it into another repository for example. This should prevent the external data from getting into your inferencing, applying of rules, SPARQLing and other kinds of deducing knowledge that will influence the behaviour of your application. If your application requires the external data to get into the mix, then you really have to deal with context, trust and rating.
In the same way you should of course never put confidential data (user passwords and email addresses) in the same repository as publicly accessible data.
In your store you might use quads to associate triples with a graph URI. Then, when retrieving RDF data from external documents, you could store it using the URI of the document as the graph URI. That way you will always know where the data came from and can treat it in this context. Be careful though: some RDF formats allow you to define named graphs inside of documents. When parsing those documents, your API might probably already associate the triples with a named graph and then, when you store them, store several quads: one for each named graph they're attached to (since you provide a graph URI yourself). As far as I'm aware, the Sesame API would in this case overwrite any graph URIs that the document attached to the triples - your mileage may vary. :-)
So, the problem here is: if in any way the graph URIs in the documents get into your store, then the documents can inject foreign-document data. That is: document A contains triples which are associated with a graph URI which is the URI of document B, thus some data in document A will end up in your store as being from document B (if that's how you interpret the graph URIs).
Doesn't sound very threatening? Why would someone do that? Well, an example: there's a new semantic search website for travel stuff, called UpTake. Read about it on ReadWriteWeb or Paul Miller's blog post on ZDNet. They pull in information about hotels and places to stay and reviews and stuff from lots of sites. Now imagine one of their sources wanted to say something bad about another competing source or about a hotel. How could they do that? Just say "they suck"? No, not effective enough. If other reviews are mostly positive, it will just be regarded as noise. So instead they could publish wrong facts about their competitor as if they stated them. If UpTake would read in an RDF document from them which contains a named graph and that graph is given the URI of a document of the competitor, then there's a danger that they store the data in the graph as coming from the competitor's document.
You could call this vulnerability named graph spoofing or context spoofing. There might be good use cases for accepting named graphs inside externally loaded documents but be careful when you treat graph URIs to mean source documents.
Another danger comes from the power of the N3 format. Note that N3 can do much more than just express the RDF model. In fact, N3 is said to be a Turing-complete language. So if your library can understand all of N3, then it might not only use its formulae (rules) for inferencing (which alone can bring enough trouble) but really execute the N3. Thus, you could get N3 injections.
Apart from security holes, there are other possible attacks. You might want to put limits on SPARQL access: size limits for the requests, size limits for the replies, time limits for the replies, maximum number of requests per day per IP address, etc. There's a reason people don't offer direct SQL read-access to their public data on their database servers. It could provide the users with endless possiblities but it might just as well let them crash your server.
