However important it may be for application secrets to be maintained someplace other than in source code, they aren’t secure if the client runs in a browser.Let’s examine this further by looking into one technique used to separate data from source code and how easy it is to fall into the trap of thinking that it provides a degree of security.Environment variables are used to externalize data by moving it from source code into a file, like the .env file..The additional step of adding this files name to .gitignore prevents git push commands from uploading it to the GitHub repo where, for public repos, it would be available to anyone.Figure 2 — Maintaining Secrets in .envNot only does this hide the environment variable value in the code, but referencing it by a well-defined name also adds clarity to the source program.A Dirty Little SecretOkay, it’s not really a secret, but it is often overlooked that the .env file is not encrypted..In the case of Create React App, this can be verified using the Developer Tools option of your browser to examine the bundle located in the build/static/js directory..Here you’ll find that 0.chunk.js contains the environment variables and their values in plaintext.Figure 3 — Plaintext Environment Variable in the BrowserSo how is using environment variables better than defining secrets in source code?.Doesn’t this mean the application is still at risk?The answer is that placing secrets in environment variables provides no significant increase in security nor does it decrease risk..The simple fact is that client-side data in the browser cannot be adequately secured and at best this technique only keeps sensitive data out of plain sight.It is tempting to consider a scenario where code splitting would be used to defer the download of scripts containing environment variables until after the application has authenticated the user..But this violates the concept of defense in depth if the client computer is compromised since the file system will be accessible to bad actors.The SolutionPhoto by Olav Ahrens Røtne on UnsplashUnlike clients, server applications can be adequately secured to protect sensitive data..These protections include the use of OAuth services to provide an additional level of authentication and access control, encryption to protect data at rest, and protocols such as HTTPS and TLS to protect data in motion.Figure 4 — Client/Server Application ArchitectureThe dilemma of how to protect application secrets can be solved by implementing a server-side application API that acts as a proxy to insulate the client app from the service providers it uses..Rather than using secrets on the client-side to authenticate to a service, the API authenticates from the server application to the external service, makes the requests, and then returns only the results to the client..At no point are private keys or secrets exposed to the client.Wrapping It UpPhoto by Miguel A..Amutio on UnsplashProviding users with the peace of mind that you’ve taken the steps necessary to secure their information requires careful planning, a well-thought-out security strategy based on defense in depth, and attention to detail.It’s not enough to rely on “.islands of technology.” Robustly addressing security requires an understanding of how information flows between components to identify gaps, weaknesses, and how to resolve them.It is encouraging if the issue of client-side application security concerns you and you’ve grappled with this problem..As a Web Developer, recognizing and accepting that security starts with you shows that you are a responsible individual and you take your craft seriously.Keep it up and be safe out there!. More details