Looking at public String resourceKey(AbsoluteLocation resource) {...} we assume the resource is an absolute location. Meaning it must carry the bucketName. Using resourcePath.substring(resourcePath.indexOf(bucketName) + bucketName.length()) we trim the first occurrence of the string bucketName. If the resource key contains a member matching the bucketName, this won't be affected.

This is, the resource type T in AbsoluteLocation<T> must make sure the absolute resource path always starts with the bucketName. Therefore, the "vulnerable datasafepath" stated above is not a valid reference to an absolute location.

so then the actual error is that the WriteToInboxImpl.java doesnt prefix the rootbucket ?

Not seeing the error in https://github.com/adorsys/datasafe/blob/develop/datasafe-inbox/datasafe-inbox-impl/src/main/java/de/adorsys/datasafe/inbox/impl/actions/WriteToInboxImpl.java. Can you elaborate?

wel it doesnt make sure the request is prefixed wtih the root bucket . we'Re using InboxService.write(WriteRequest.forDefaultPublic()) to write things into the inbox so either the WriteRequest should make sure the rootBucket is prepended (though its not gonna be convenient to inject it there since its staic) or the WriteToInboxImpl.java should make it sure when reading out the request.getLocation() or alternatively somewhere in the following resolver.resolveRelativeToPublicInbox

Hello @francis-pouatcha this change implies indirectly ensuring that the file paths in the generateUserWithInboxAndOutbox function and related test methods are correctly set up. As it is crucial to avoid NoSuchFileException , are there any other ways we can handle this ?

https://github.com/adorsys/datasafe/blob/develop/datasafe-examples/datasafe-examples-business/src/test/java/de/adorsys/datasafe/examples/business/filesystem/BaseUserOperationsTestWithDefaultDatasafeTest.java