Validation / Add Shacl validator

[fxprunayre]

Shacl validation is using Shacl shapes to validate RDF document and can be done with Jena library (library used for the DCAT harvester).

Shacl rules are usually published with DCAT profiles eg. https://semiceu.github.io/DCAT-AP/releases/3.0.1/#validation-of-dcat-ap. Shacl is used by various tools like https://data.europa.eu/mqa/shacl-validator-ui/data-provision or https://www.itb.ec.europa.eu/shacl/dcat-ap/upload but it is sometimes hard to analyse errors and be able to easily improve DCAT compatibility. This work was also the opportunity to get more knowledge about how RDF validation works (eg. loading shapes, loading ontologies, infer model) and if DCAT validation can be similar to validation provided by INSPIRE. Validation using Shacl is quite dependent on the validation configuration and background knowledge provided so validation results depends a lot on that.

Changes:

• API / Add endpoints to retrieve testsuites (similar to INSPIRE ones). A testsuite is a collection of shapes and ontologies.
• API / Add endpoints to run a testsuite on a record

• Editor / Start and display simple validation report

Notes:

• A Shacl testsuites has to be applied on a particular formatter (currently hardcoded on eu-dcat-ap-hvd).
• Shacl reports (similar to XSD) is quite technical pointing to object in the RDF graph and is not simple to understand for end users. To mitigate this, schematron analysis (eg. Standard / ISO / Schematron for DCAT HVD requirements #8555) could be a way to anticipate Shacl errors based on the ISO document analysis providing better context and hints for each types of rules.
• This is maybe not necessary to be merge in main depending on people interested in that topic. It can also depends on the availability on "official" online validator that GeoNetwork could maybe use directly.

Checklist

• I have read the contribution guidelines
• Pull request provided for main branch, backports managed with label
• Good housekeeping of code, cleaning up comments, tests, and documentation
• Clean commit history broken into understandable chucks, avoiding big commits with hundreds of files, cautious of reformatting and whitespace changes
• Clean commit messages, longer verbose messages are encouraged
• API Changes are identified in commit messages
• Testing provided for features or enhancements using automatic tests
• User documentation provided for new features or enhancements in manual
• Build documentation provided for development instructions in README.md files
• Library management using pom.xml dependency management. Update build documentation with intended library use and library tutorials or documentation

Funded by Service Public de Wallonie

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

To fix this, catch all exceptions thrown from the shaclValidationService.validate(...) invocation within the controller method. Log the exception internally (with stack trace or message for auditing and debugging), but return a generic error message to the client, avoiding exposure of the original exception message or stack trace.

• Where: Only change the controller method body in ShaclValidationApi.java, lines 142–146.
• What:
  • Surround the body with a try-catch block.
  • On exception, log the error (using any available logger, e.g., LoggerFactory or org.apache.log4j.Logger—but only use what we see imported, or add a well-known logger import).
  • Return a generic error message, such as "Validation failed due to an internal error." Optionally set an appropriate HTTP status code (e.g., 500).
  • The controller's signature returns a String (likely serialised as content), so send the generic message as the response.
• Extra imports: If a logger is not yet available, import org.slf4j.Logger and org.slf4j.LoggerFactory or use another suitable (already imported) logger.

---

To resolve this issue, the application should prevent untrusted user input from being reflected directly into output fields in a way that could cause security issues. The most robust solution is to either:

1. Validate or restrict the possible values of the formatter (and other relevant inputs) using a server-side whitelist (i.e., only permit specific, expected string values); or
2. If the set of allowed values can’t be strictly enumerated, ensure user-controlled string data is properly escaped when embedded in responses.

Given the context (the formatter parameter refers to a set of possible format names, often documented in the API as dcat, eu-dcat-ap, etc.), a whitelist of allowed names is best and changes very little functional behavior. This should be enforced in validateRecordUsingShacl (or inside validate). If an invalid value is supplied, return a clear error message.

Alternatively (for completeness or if new formatters may be added dynamically), any string values returned to the client (especially those embedded in error/status messages in JSON) should be escaped to prevent the formation of illegal or executable content. For JSON, this is typically handled by constructing your response as a POJO and serializing with a safe library (e.g., Jackson), or at minimum escaping quotes and special characters inside the string.

To implement the whitelist fix:

• Import a set of allowed values at the top of the API class (or service).
• Prior to passing formatter to shaclValidationService.validate, check if it is present in the allowed set. If not, throw an exception or return an error JSON stating the allowed values.

To implement escaping as a defense-in-depth:

• In buildStatusResponse, escape special characters in the message parameter using a library like org.apache.commons.text.StringEscapeUtils.escapeJson() before including them in the response string.

We will implement BOTH: adding a whitelist check for formatter in the API, and ensuring messages are safely encoded in responses (using Apache Commons Text for JSON escape).

---

To fix this issue, user-supplied shape file names in shaclFiles should be strictly validated to prevent path traversal and ensure they are only file names (single path component), with no path separators or ".." references. The best fix is to check each supplied file name for forbidden components ("/", "\", "..") before using it to construct a resolved Path. Alternatively or additionally, after resolution, we can check that the canonical path of the resolved file remains within the intended shacl directory. Implement this check at the start of parseShapesFromFiles. Reject any file names failing the check with a clear error.

Changes needed:

• In parseShapesFromFiles, validate each shaclFile in shaclFiles to ensure it:
  • Does not contain "/" or "\" or "..".
  • After resolution, remains strictly inside shaclRulesFolder.
• If any check fails, throw an exception.

No new methods or imports required other than possibly java.nio.file.Paths and/or java.io.IOException.