so here is an update. The frontend and backend's .env file contains the same 30 keys, and same 30 hashes. Its pre-shared, and symmetric. If frontend makes post request, its sends an id, and the encrypted payload. id indicates which key was used. The frontend is react js, and backend is node js

@MFSCraft: If even unauthenticated clients can get the keys, or if anybody can register and then get the keys, they're indeed useless. Still, if there's any way you can talk to the original developers or obtain design documents, figure out what the original goal was and why this implementation was chosen. Was this about traffic encryption? Or encryption at rest? Maybe something else entirely?

no it was not encryption at rest either. the payload is immediately decrypted once it arrives to the node js server to read the encrypted payload's content. also its hard to get anything from the previous dev. They're not cooperative.

@MFSCraft: Are you working on the code as part of your job? Is this a project for some customer? As there's apparently money involved, I'm pretty sure this isn't just a hobby project. Then there should be a contract with requirements which say what the code is supposed to do. And there should be somebody you can ask about this – like your boss. If the requirement is “The traffic must be encrypted in transit” and nothing else, then suggest using TLS and getting rid of the useless keys. If there are other requirements, you need to find out what those are.

Yes, I am working on the code as part of my job. and it is not a hobby project. This project is not for a customer but for my boss/employer. The website was developed by a third-party vendor based overseas, and the employer hired me as their in-house developer to maintain, review, and improve the codebase. The only requirement I received from my employer was to "make sure it's secure". To my surprise, I saw many amateur-level code, and the backend's node js is v16, which is EOL. I was also tasked to rewrite the whole thing with the 'latest standards', using versions with LTS.

@Ja1024 I'm not sure why you're insisting so hard that someone must have answers. While it sounds like MFS Craft has some access to the prior dev I have worked on plenty of projects where the SME is no longer with the company. It happens.

@MiniRagnarok: Who cares about the prior developer? I said the OP needs to understand the requirements and the implementation before throwing code out. Do you disagree? Talking to prior developers is one option, but if the devs are uncooperative, that's also fine. However, there should be somebody who knows the requirements – in the case of the OP's, this is an internal project by their employer, so they do have somebody to ask. If you're working on a project where nobody knows why the project even exists, there's something very wrong.

@Ja1024 You seem to be under the impression that all projects have clear requirements or that this is some way to figure out the original goal either via a developer or documentation. That's what doesn't make sense. I've been handed code from a department that was sold to another company and I had nothing to go off of other than the source code itself. It happens.

@MiniRagnarok: When companies pay a developer to work on a project, they rarely do that just for fun. They want something from the project. Sometimes the requirements are clearly written down, sometimes they’re informal (especially in the case of internal projects). I’ve encountered all of this. My point is: Unless the company is entirely dysfunctional and pays its employees to do nothing, somebody knows what the project is for. The OP already found that person (their boss), so I’m not sure what you’re arguing for or against.

@MiniRagnarok: In any case: When working on a project with unclear requirements, I would definitely not assume that nobody cares about the project and that each developer can do whatever they feel like (like randomly removing code). Unclear requirements don’t mean no requirements.

@Ja1024 There are two ideas being conflated here. You said you wanted them to contact the original developer or requirements to figure out the original intent. That's talking about the past, not the present and is the only thing I was talking about. Your latest response to me is talking about the current requirements as a way to figure out what needs currently needs done. They have zero connection to each other.

@MiniRagnarok: No offense, but if it’s your experience that the work of developers is completely detached from the project requirements, or that the requirements fundamentally change during a project, then you must have worked on some pretty dysfunctional projects. Sure, both can happen. Sometimes developers have no idea what they’re doing, and sometimes customers (or whoever initiated the project) have no clue what they want. But if a company is in good shape and has competent (and friendly) developers, asking them why they made specific implementation choices is often [...]

@MiniRagnarok: [...] the quickest way to figure out a) what the project is all about and b) how the implementation works. In the OP’s case, the prior developer seems uselesss in every aspect, so I agree that asking them won’t help at all. I’m fine with that. This is why I told the OP to instead look for somebody else who knows the requirements. The OP did that, explained this is an internal project they got directly from their boss and gave some background. Great! I believe my comments have been fully addressed by the OP, and I hope the extra information was beneficial to everybody. That's all

Thank you everyone for your input. We have decided to exclude the second encryption layer on our new frontend code. However, I am open to other ideas. If anyone has handled with sensitive data like this before, feel free to answer.

@Ja1024 I think you work for a very specific industry and you have a very specific mindset because of that. I don't sell software so I don't have a customer/client relationship. My point is more that you should be far more flexible here. Insisting that OP needs to find original intent for some source code he's working on makes zero sense. There's a lot of ways that original intent is lost to time. If he has it or can get it, great but let's not insist it exists.

@MiniRagnarok: Did you miss that the OP was able to get useful information, came to a reasonable conclusion, marked my reply as an answer and thanked everybody for their advice? The only person who is still strangely unhappy with the replies or comments is you. What exactly do you have a problem with? That I told the OP to do some research before deleting code? The whole point of asking a question on this site is to make an informed decision, and I’ve made multiple suggestions to help with that. I'm not quite sure what your goal is.

@MiniRagnarok: When I write an answer, I care about the concrete problem at hand, not the issues of other projects somebody else may have encountered at some point in their career. Yes, there absolutely are projects so dysfunctional that the developers have to reverse-engineer the code to get useful information. Thankfully, there are also projects where you can talk to developers, get documentation and figure out the requirements. The only way to find this out is to ask. It’s a bit of work and not necessarily pleasant, but if you do get the information you’re looking for, it definitely helps.

@Ja1024 Your answer is fine. All I've said the entire time is "I'm not sure why you're insisting so hard that someone must have answers." after you pushed for that a second time in the comments. It's not helpful as there's plenty of circumstances where that's not possible and all I was doing was pointing that out to you. After so much back and forth it's clear that it was or still is a blind spot for you. Even now you are under the impression that it's only projects that are extremely dysfunctional that you wouldn't be able to find out why something was the way it was. I think it's the norm.

@MiniRagnarok: I think you still don’t understand that I’ve made multiple suggestions to gather any useful information. I’ve suggested trying to talk the original developer to understand why they’ve chosen this implementation – they didn’t want to talk, fine. Then I’ve suggested getting any info about what the whole point of this project is. That doesn’t mean formal requirements. It can be some vague idea some superior has in their head. This worked out. If it hadn’t, I would have suggested something else. This is very basic information gathering which any developer can and should do.

@MiniRagnarok: This is exactly your problem: You've become obsessed with this one aspect instead of seeing the bigger picture of information gathering. Trying to find the original intent is one possible approach. One among many. It can be successful and yield a deep understanding of the code. And it can fail. Then you move on. The idea that I somehow forced the OP to find the intent of the code only exists in your head. I've been a developer myself, I know that sometimes nobody remembers what the intent was, or the persons who do aren't reachable. Then you move on. Which you should too.

@Ja1024 I don't think there's anything I disagree with in your latest comment and never said I did.