In the Springboot/Java software development, I often see people building out services in which they then call other services from. This is often a very big mistake as it obfuscates those service calls and makes it harder to test your application.

Now this isn’t always a bad thing BUT it should not be done without reason. And the biggest reason for this happening is that people just don’t know to put service calls into an orchestration layer (or they forgot).

But what is an Orchestration Layer? Let’s take a dive into the many different classes that do orchestration and what the orchestration layer is.

What is the Orchestration Layer

An orchestration layer acts as a ‘coordinator’ pulling related tasks together for a single outcome. Think of it like a chef that pulls all the dishes together to create a meal that then gets served to the client. The chef doesn’t make each dish of the meal; for that they rely on the kitchen staff assigned to each different area.

The same is true for the orchestration layer.

In Java, an orchestration layer is a centralized software component that coordinates those services, API calls and/or data pipelines to complete a single business process. The orchestrator does not perform the underlying business logic itself… it merely calls and coordinates them.

That business logic is separated into services and the orchestration layer calls/coordinates between these services.

Examples Of Orchestration Layer in Java/Springboot

Depending on what you are building, the orchastration layer exists in different places in Springboot. For example, for a:

• CLI : If you are building a CLI app, the orchestration can exist in either the MAIN function or in a bootstrap/init class called by the applicationrunner/clirunner.
• Scheduler : For a cron job/scheduler, the orchestration is handled in the function annotated with @Scheduler
• Web App: Orchestration is commonly done in the @Controller or @RestController for almost all web apps. This is the most common orchestrator.

Where to place logic for the Orchestration Layer?

The orchestrator looks for the ‘business logic’ in @Services.

Now normally, you place all business logic in services as it is meant for business logic specifically.

You CAN place it in @Components BUT that is not the intent of that class; components are mainly used for Utility classes, schedulers, and generic helpers due to the fact that components can be used in BOTH orchestration layer and service layer (see example below).

And Thats It!

Now you understand the difference between orchstration and service layers and when to use either.

If you liked this article, please like and subscribe.

Critical Issues(???)

These are the issues that the AI tool rated as ‘CRITICAL’ (including the fact that printlns were used in places that needed logging)…

SQL Injection / Parameter Validation Risk

• AI Assumption: The createApiDescriptor() method processes user-supplied values from JSON configuration files without sufficient validation. While mockData is validated, foreign key references and parameter types are not escaped before being used in cache operations.
• Actual Risk: LOW. The application uses external properties files for loading configuration settings. They are stored in the running users home directory. This means that in order to craft a malicious file, the user would nee WRITE privileges locally on that machine for that user. In other words, you are already FUCKED if this happens.

Hardcoded Credentials & String Interpolation

• AI Assumption: Mail sender credentials use string interpolation ("${apiProperties.getMail().getUsername()}"), which means they're rendered as strings, not actual values. This suggests incomplete implementation.
• Actual Risk: None. This is merely bad formatting

Unhandled Exceptions with System.exit(0)

• AI Assumption: The framework calls System.exit(0) on initialization failures, which is too aggressive for a library (not an application). This crashes the entire JVM without allowing graceful degradation.
• Actual Risk: None. We want the server to DIE if key configuration fails; it should not continue processing.

Insecure Error Messages with println() in Production Code

• AI Assumption: Direct use of println() for logging errors to stdout. No structured logging for production environments; errors may be lost.
• Actual Risk: None. Merely bad logging

Deprecated AGPL License Conflict in Documentation

• AI Assumption: BeapiWebAutoConfiguration.groovy header mentions "AGPL v2 License," but README.md states "Reciprocal Public License (RPL-1.5)". Inconsistent licensing.
• Actual Risk: This is laughable that this registered as CRITICAL. Merely did not update license in classes

High Priority Issues

I don’t know how AI thinks a ‘println’ is more critical than a NullPointerException but this is the ranking I got…

NullPointerException Risk in ApiCacheService.getApiCache()

• AI Assumption: cacheManager?.getCache('ApiCache')?.get(controllername)?.get() chains optional operations but throws generic exceptions on failure.
• Actual Risk: Very Low (on Blocking/Synchronous apis). BUT… it is a risk that SHOULD be mitigated. So score one for AI.

Security Filter Chain Ordering Issues

• AI Assumption:: Filters are added without verifying their order relative to other Spring Security filters. JwtRequestFilter and RequestInitializationFilter may not execute in intended order.
• Actual Risk: None. You can declare the order in the FilterRegistrationBean otherwise the order defaults.

etc etc etc

Review?

The AI code review greatly exagerated typos and issues and thought there was greater threat than there was in almost everything.

It was good at finding typos and minor issues but does not understand ‘architecture’

Now I would not say it is not without value but the value that it adds in greatly exaggerated. I was pleased to see some things that could be fixed and issues that had gotten past me.

Code reviews still require eyeballs on the code but this is a nice additive feature for assists.

• IAM
• OpenAPI
• Gateway

But there are inherent security issues with every single one of these tools that cause them to be HORRIBLE for security and governance.

In this article, I will go over the issues with each one of these tools and explain why they make you apis easy to hack and difficult to share setup parameters within your network.

OpenAPI : Not a RULES doc

So if you ask ChatGPT (or others) if OpenApi is a rules doc, it will respond like so:

So what does this mean? It means that it does not handle security rules… only routing data. Things like RBAC/ABAC which are tightly bound to the route are not being implemented or documented.

So when an ADMIN or USER role accesses an endpoint, there is no parameter telling the client whether it has access or not and what parameters to send: OpenAPI just uses the same parameters for ALL ROLES!

Additionally, it has no way to define Swagger api docs to show appropriate information to each separate ROLE; an ADMIN and USER will see the same apidocs thus disclosing information about your backend and giving a USER a false sense of access.

Worst of all, This can lead to privilege escalation.

Gateway/IAM: Only good for JWT/TLS

Try asking ChatGPT about what security should be handled in the api gateway and you will get an interesting answer:

The ‘Notably Excluded’ part at the bottom dictates why these pieces are left out and that they have to be INTEGRATED into the api application to avoid being bypassed.

This is because an ‘internal redirect’ can bypass all security at the gateway because the request is re-used in the application.

This is a double-edged sword too because SOOOOOOOO many developers rely on tools like IAM/Gateway to secure their apis when all they really are good for is the handling of the JWT and TLS.

Bringing These Up With Vendors

Now first, you have to understand that vendors are interested in creating a tool that hits the largest market they can and they ignore what tyhey don’t understand.

I have talked to all the major gateway vendors at conferences AND in their offices and they all agree: you have to create these security rules in your api backend.

Unfortunately, I had a non-helpful talk with the OpenAPI team which illustrated their lack of understanding of the api call flow.

The OpenAPI committers called internal redirects ‘made up’ and the lead for the project even LIED and stated that Roy Fielding said they were.

Roy Fielding then interjected that he NEVER stated such and that internal redirects have existed since the very first HTTP server.

So you cannot rely on expertise of creators behind tools as even they are ignorant or motivated by pushing their own tools (rather than fixing them).

In Closing

Api security requires a hybrid of tools and integration of these rules into both schemas and functionality in order for your api backend to be fully secure.

Take every word from vendors with a HUGE GRAIN of salt.

Following up on my previous story, I wanted to implement a fully secured api backend with:

• authorization/authentication
• RBAC/ABAC
• session management

Most AI generated code only focuses on authentication/authorization and skips all other security. This is mainly due to the fact that the models it is trained mainly implements JWT tokens and nothing else.

So we thought we would try to see if AI can handle writing security.

Tools

Again, we are still using Java and Springboot due to their robust and mature securty tools and libraries.

Authorization/Authentication (Score: A)

Claude did great at adding this functionality with a filter and then adding an endpoint for ‘login’.

This is 100% expected because the vast majority of models it is trained on implements this functionality.

RBAC/ABAC (Score: D)

Claude was able to implement RBAC ok but when asking it to implement ABAC for the request/response, it hardcoded functionality into the endpoint as a one-off; in other words, it did not implement the functionality in a re-usable way.

It also took 3–4 iterations to get this even semi-correct.

This code was overly complex and not reusable. It ALSO did not implement ABAC for the RESPONSE dataset per ROLE so was only a partial implementation.

Additionally, it added endpoints that I did not ask for and even wiped out previous endpoints that I HAD asked for. I had to do a reversion in order to get the original endpoints back.

Session Management (Score: F)

This is where it completely failed. Claude could not associate the JWT with the session and had a nervous breakdown trying over and over to implement this.

Conclusion

As we added more and more security to the code, Claude got worse and worse. This is consistent behaviour we have witnessed in Claude as well as other models.

• JWT (complete) : 1 iteration
• RBAC (complete): 2–3 iterations
• ABAC (partial) : 3–4 iterations
• Session management (incomplete): 6 iterations

Most AI can only do the basics and the more complexity you add, the more mistakes it starts making.

This is a common issue with AI in that the more complexity added, the more mistakes it starts to make.

I have tested this by switching some of the functionality and it seems the first 1–2 items added can be accomplished for the most part but trying to accomplish a completely secure application is impossible.

This seems to be an inherent scalability issue with AI and something that cannot be fixed with existing models.

Over the last week, I have been writing about AI’s and vibe coding and how they cannot handle security or write secure code.

Below is a list of functionality that I have been trying to implement in AI with a vibe coded api endpoint:

• Access Control
• Authentication / Authorization
• Session Management
• Transport Security
• Rate Limiting / Throttling
• CORS / IP whitelisting
• Internal Redirects & Workflow Control
• API Versioning & Deprecation

From that list, only authentication / authorization is the only consistent feature that most models can implement… everything else is a bit of a gamble or the LLM’s simply cannot implement.

So I thought I would write a series of articles on AI’s capabilities in security and how the top models for coding respond for each of these features.

Today I will start with Access Control (RBAC/ABAC)

The Tools

I will be asking each of the models to code using springboot and Java as they have a very mature set of security tools and libraries.

ChatGPT (Score : C+)

This took me about 7 iterations and it WAS able to create the code but it was a mess with no ability to handle api governance since all the RULES were hardcoded using annotations

Additionally, it was trying to handle all ABAC functionality in the endpoint rather than in a filter or interceptor; this makes it impossible to implement with any caching scheme and is HIGHLY redundant.

This literally makes it so that you would have to include code like this in EVERY SINGLE ENDPOINT! This makes any api development highly convoluted, messy and overly verbose.

SCORE: C — It accomplished the bare minimum but not in a way that made it usable for other endpoints.

Claude (Score: F)

I tried over and over with Claude and it just couldn’t do it… regardless of the number of iterations. It had problems implementing both RBAC and/or ABAC and just failed miserably.

Also, I didn’t ask for a JWT but it implemented one anyway.

AND… it’s default endpoint was ‘login’ which I did not ask it to implement.

Claude was making assumptions all over the place and this was not in it’s favor.

Score : F

Copilot (Score: F)

Copilot also failed at this and could not implement ABAC; it could implement RBAC using hardcoded annotations (just like Claude) but could not properly secure request variables.

Score : F

Conclusion

I was surprised that ChatGPT got as far as it did thus showing some improvement in it’s capability to AT LEAST implement the requested security feature … BUT it did not do it in a way that the code could be used across multiple apis.

I also was not surprised by Claude or Copilot’s failures as they responded pretty much the way they have on previous passes.

Still I must say I was surprised that ChatGPT got it partially right.

Claude is an AI that specializes in writing code and should be able to handle it. So I gave it a try and the results were not great.

First off, when I asked it about it’s ability to handle security, Claude was confident and stated:

So I tested it out

The Sample Application

First, I asked it to do everything it would need to secure an api backend in a Java/Springboot application and the only thing it did was JWT tokens thus missing 90% of required security for the application.

It hallucinated and literally insisted that it was doing input/output validation but did not have an RBAC or ABAC implementation.

It also insisted on putting this behind a gateway which ONLY PROTECTS ON THE INGRESS thus ignoring its own security responsibilities:

Additionally, it also didn’t associate the JWT with the session to avoid session hijacking; this alone was an even bigger concern as a man-in-the-middle attack can grab a token and impersonate an individual.

Second Iteration

On the second iteration, it continued to hallucinate by thinking it was associating the token with the session but had not implemented anything.

It also thought it had implemented RBAC/ABAC but still had not.

Third Iteration

This time, it was attempting to pass the session with the token rather than associating the token with the session in the application. This potentially leads to even EASIER token hijacking…

TECHNICALLY, this COULD WORK if you then were also checking to see if session_id sent by token matched (which Claude is not) BUT you do not want to send private information in the token as it can be abused… which is what Claude is doing.

It DID hardcode an RBAC solution but again failed utterly to build an ABAC solution based on sent ROLES for both request/response params; it WAS checking the request params but was not basing them on the sent ROLE thus allowing for users to get other ROLES data per endpoint.

Conclusion

As ChatGPT stated that it’s models did not have enough data to properly handle security, Claude demonstrated this.

With every iteration, the code just got more and more convoluted without actually implementing what was being asked.

The filters and classes it was using were correct (which I was impressed with) but it didn’t understand what had to be done to implement these security behaviours.

All in all I would say this is another fail for AI in handling security.

UPDATE (8–7–2025)

I tried again later by just telling it to create a filter that associates the JWT token with the session and after two tries, it did succeed. BUT it still could not properly handle RBAC/ABAC for the request response.

Apparently it can do some things if you task it with one thing at a time but when it comes to more complex scenarios like RBAC/ABAC, which has to be integrated altogether and are interdependent, it easily gets confused.