pjfanning opened a new pull request, #1263: URL: https://github.com/apache/pekko-http/pull/1263
### Motivation `getFromResource` passes the resource name to the class loader as given: ```scala 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](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
