docs: warn that getFromResource does not filter its resource name

[pjfanning]

Motivation

getFromResource passes the resource name to the class loader as given:

Option(classLoader.getResource(resourceName)).flatMap(ResourceFile.apply)

Its only guard is the trailing-slash check that stops directory resources being served. Unlike getFromResourceDirectory — which routes the request path through safeJoinPaths and rejects .. and separator characters — it applies no traversal filtering at all.

An application that builds the name from request input, for example getFromResource(s"public/$name"), can therefore be made to resolve a resource outside the intended prefix against a directory-backed class loader (application.conf, logback.xml, …). That matches the trust model of the low-level getFromFile, but the scaladoc did not say so, and the contrast with the sibling directive makes it easy to miss.

Not exploitable through the getFromResourceDirectory wrapper, which is unaffected.

Modification

Document the behaviour on both the Scala and the Java DSL entry points, pointing at getFromResourceDirectory as the filtering alternative. No behaviour change.

Result

The trust boundary of the directive is stated where a caller reads it.

Tests

Not run - docs only

(sbt http/compile and sbt http/mimaReportBinaryIssues both pass; native scalafmt clean.)

References

None - documents that getFromResource does not filter its resource name

🤖 Generated with Claude Code