Summary
The ApiOriginFilter.mustache templates for the JAX-RS and Java MSF4J generators install a Servlet Filter that sets Access-Control-Allow-Origin: * unconditionally on every response. Every JAX-RS / MSF4J server scaffolded by openapi-generator inherits this default and ships with permissive CORS out of the box.
Affected template files
modules/openapi-generator/src/main/resources/JavaJaxRS/ApiOriginFilter.mustachemodules/openapi-generator/src/main/resources/JavaJaxRS/resteasy/ApiOriginFilter.mustachemodules/openapi-generator/src/main/resources/java-msf4j-server/ApiOriginFilter.mustache
Template body (JavaJaxRS):
```java
public class ApiOriginFilter implements {{javaxPackage}}.servlet.Filter {
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
HttpServletResponse res = (HttpServletResponse) response;
res.addHeader("Access-Control-Allow-Origin", "*"); // ← wildcard CORS
res.addHeader("Access-Control-Allow-Methods", "GET, POST, DELETE, PUT");
res.addHeader("Access-Control-Allow-Headers", "Content-Type");
chain.doFilter(request, response);
}
...
}
```
Risk
A wildcard Access-Control-Allow-Origin: * lets any web origin make cross-origin reads of API responses. In combination with credentialed requests (cookies / Authorization headers) this is typically harmless because browsers reject * with credentials, but it still:
- Defeats same-origin protection for unauthenticated APIs that expose sensitive data.
- Sets the wrong precedent for downstream users who frequently add
Access-Control-Allow-Credentials: true later without realising the wildcard then becomes unsafe.
- Generated samples (
samples/server/petstore/jaxrs-jersey/.../ApiOriginFilter.java, etc.) ship this code as canonical reference — encouraging copy/paste into production.
Suggested fix
Three options:
- Configurable origin list with safe default: take an allowlist from a Mustache variable / config, default to a single origin (
http://localhost:3000) or empty (no filter).
- Reflect the request
Origin against an allowlist: read request.getHeader("Origin"), compare against a config-driven list, only echo on match.
- Document and warn: keep template as-is but emit a
// TODO: replace wildcard with allowlist before production comment.
(1) or (2) is preferred; (3) is the minimum.
Severity
Low–moderate. Wildcard CORS alone is not a confidentiality breach for credentialed APIs (browser-enforced), but it sets a poor default and propagates to every JAX-RS / MSF4J server generated by this tool. Worth fixing at the template once.
Discovery
Found while running an LLM-assisted SAST sweep over the top 100 starred Java repositories on GitHub. Filed alongside other upstream reports from the same sweep (baomidou/mybatis-plus#7091, languagetool-org/languagetool#12041, plantuml/plantuml#2759). Happy to send a PR with the allowlist-based template if maintainers agree on the direction.
Summary
The
ApiOriginFilter.mustachetemplates for the JAX-RS and Java MSF4J generators install a ServletFilterthat setsAccess-Control-Allow-Origin: *unconditionally on every response. Every JAX-RS / MSF4J server scaffolded by openapi-generator inherits this default and ships with permissive CORS out of the box.Affected template files
modules/openapi-generator/src/main/resources/JavaJaxRS/ApiOriginFilter.mustachemodules/openapi-generator/src/main/resources/JavaJaxRS/resteasy/ApiOriginFilter.mustachemodules/openapi-generator/src/main/resources/java-msf4j-server/ApiOriginFilter.mustacheTemplate body (JavaJaxRS):
```java
public class ApiOriginFilter implements {{javaxPackage}}.servlet.Filter {
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
HttpServletResponse res = (HttpServletResponse) response;
res.addHeader("Access-Control-Allow-Origin", "*"); // ← wildcard CORS
res.addHeader("Access-Control-Allow-Methods", "GET, POST, DELETE, PUT");
res.addHeader("Access-Control-Allow-Headers", "Content-Type");
chain.doFilter(request, response);
}
...
}
```
Risk
A wildcard
Access-Control-Allow-Origin: *lets any web origin make cross-origin reads of API responses. In combination with credentialed requests (cookies / Authorization headers) this is typically harmless because browsers reject*with credentials, but it still:Access-Control-Allow-Credentials: truelater without realising the wildcard then becomes unsafe.samples/server/petstore/jaxrs-jersey/.../ApiOriginFilter.java, etc.) ship this code as canonical reference — encouraging copy/paste into production.Suggested fix
Three options:
http://localhost:3000) or empty (no filter).Originagainst an allowlist: readrequest.getHeader("Origin"), compare against a config-driven list, only echo on match.// TODO: replace wildcard with allowlist before productioncomment.(1) or (2) is preferred; (3) is the minimum.
Severity
Low–moderate. Wildcard CORS alone is not a confidentiality breach for credentialed APIs (browser-enforced), but it sets a poor default and propagates to every JAX-RS / MSF4J server generated by this tool. Worth fixing at the template once.
Discovery
Found while running an LLM-assisted SAST sweep over the top 100 starred Java repositories on GitHub. Filed alongside other upstream reports from the same sweep (baomidou/mybatis-plus#7091, languagetool-org/languagetool#12041, plantuml/plantuml#2759). Happy to send a PR with the allowlist-based template if maintainers agree on the direction.