DEV Community: Mark Benjamin

Founders, what are you building this week? I'm working on a platform for makers like us. Launch your startup for $0 and build in public with us. Submit your startup today: https://pavelaunch.com #solopreneur #buildinpublic #saas

Mark Benjamin — Fri, 12 Dec 2025 20:32:13 +0000

PaveLaunch - Launch and Discover Products

PaveLaunch is the premier destination for creators to showcase their latest inventions and for tech enthusiasts to explore cutting-edge innovations.

pavelaunch.com

[Possible Fix] Inflight reported as a vulnerability in react project (Veracode SCA)

Mark Benjamin — Fri, 10 Nov 2023 07:26:41 +0000

If you're facing an inflight vulnerability from a veracode (or any other SCA tool) scan, then it probably comes from eslint package. This might not be the case for all scenarios but the SCA tool typically shows you a dependancy graph where you can drill down on the involved packages. In the case that it is eslint for you then here's the fix that clears the SCA scan error:

You probably have eslint under the dependancies section in the package.json (of course, duuh). Just move the eslint package into the devDependancies because that is where it belongs in the first place. The SCA tool knows that as a dev dependancy, it is only used for the development phase and will not affect the production code.

As always, I hope this helps someone 😌.

Next JS might be exposing your backend environment variables

Mark Benjamin — Wed, 08 Nov 2023 19:37:17 +0000

I recently got embarrassed by next.js at work when some API keys were found on the client-side browser cache. Even though these variables were used on the backend side, they were being exposed and it was quite confusing to me. I later did extensive research and discovered a rule of thumb to use in future to avoid such a scenario in future. I wrote this post to help you avoid such a scenario and to share the rule I came up with.

The problem

Apparently, it is not a good idea to share variables between the client and server. This was the root problem for me. Here's an example of what I did.

I had a backend file called say utils.ts which was getting values from the .env as below:

const environment = {
    someApiURL: `${process.env.SOME_API_URL}`,
    someClientKey: "someClientValue"
};

export default environment;

Then on the client, we use the someClientValue as below:

import environment from "@/utils.ts"

export default function App(){
    const [state,setState] = useState(environment.someClientKey)

    return <div>{state}</div>
}

In the examples above, the client build will also include the someApiURL and even expose its value from the .env to the client. To confirm this, we can open the browser dev tools, go to sources tab and into _next/static/pages/chunks/thepageyourcurrentlyin and try to search the someApiURL. You will find the .env value exposed.

Fix

The fix is as simple as to not mix server variables with client variables. Except that more often than not, you will not be keen enough. For me, I came up with a rule of thumb to separate frontend and backend utility and config functions to different folders so I'm always sure.

This might not seem as a common or significant issue until you expose your company's credentials to potential hackers.

Hope this helps someone.