← Back to Article List         
Securely Stored Secrets - Environment Files

Securely Stored Secrets - Environment Files

Published on 01 Oct 2026     7 min read Angular
Environment & Configuration

Can Secrets Be Securely Stored in Angular Environment Files?

1. What is a Secret?

A secret is sensitive information that must not be exposed to users or attackers.

Examples include:

Database passwords
SQL Server connection strings
JWT signing keys
OAuth client secrets
Private API keys
Azure service credentials
Storage account keys

For example:

export const environment = {
  apiUrl: 'https://api.example.com',

  // ❌ Secrets
  jwtSecret: 'my-super-secret-key',
  databasePassword: 'Password123',
  privateApiKey: 'abc123'
};

These values cannot be securely stored in Angular environment files.

2. Short Answer

No. Angular environment files cannot securely store secrets because Angular is a client-side application. Values from environment files can become part of the JavaScript delivered to the browser and can therefore be inspected by users. Secrets must remain on a trusted backend or secret-management system.

This applies to:

environment.ts
environment.development.ts
environment.uat.ts
environment.production.ts

Even:

environment.production.ts

is not a secret store.

3. Full Simple Sample

Suppose Angular needs to call an ASP.NET Core Web API, and the Web API needs a private API key to communicate with an external service.

Architecture

Angular Browser
      │
      │ HTTP
      ▼
ASP.NET Core Web API
      │
      │ Uses secret
      ▼
External Service

The secret stays on the ASP.NET Core server.

Angular — environment.ts

This is acceptable:

export const environment = {
  production: false,
  apiUrl: 'https://localhost:7001/api'
};

The API URL is not treated as a secret.

Angular — product.ts

import { inject, Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';

import { environment } from '../../environments/environment';

export interface Product {
  id: number;
  name: string;
}

@Injectable({
  providedIn: 'root'
})
export class ProductService {

  private http = inject(HttpClient);

  private apiUrl = `${environment.apiUrl}/products`;

  getProducts(): Observable<Product[]> {
    return this.http.get<Product[]>(this.apiUrl);
  }
}

Notice that Angular contains only:

environment.apiUrl

It does not contain the backend's private credentials.

4. Where Should the Secret Go?

For local ASP.NET Core development, use an appropriate server-side secret mechanism such as User Secrets rather than committing secrets to source control.

For example:

dotnet user-secrets init

Then:

dotnet user-secrets set "ExternalApi:ApiKey" "my-secret-key"

ASP.NET Core can read it through configuration:

var builder = WebApplication.CreateBuilder(args);

var apiKey =
    builder.Configuration["ExternalApi:ApiKey"];

builder.Services.AddControllers();

var app = builder.Build();

app.MapControllers();

app.Run();

In production, the secret can instead come from a server-side secret store such as:

Azure Key Vault
Environment variables
Managed secret-management service

The important point is:

Secret
  ↓
ASP.NET Core/server

not:

Secret
  ↓
Angular/browser ❌

5. Why Aren't Angular Environment Files Secure?

Suppose you write:

export const environment = {
  production: true,
  apiKey: 'SECRET-ABC-123'
};

Then build:

ng build --configuration production

Conceptually:

environment.production.ts
        ↓
Angular build
        ↓
JavaScript bundle
        ↓
Browser downloads bundle
        ↓
User can inspect client-side resources

The fact that the original TypeScript file isn't directly deployed does not make the value secret.

A secret embedded in client-side code should be considered exposed.

6. Does Minification Protect the Secret?

No.

Production builds may transform/minify code, but minification is a performance technique, not a security boundary.

For example, source code might start as:

const apiKey = 'SECRET-ABC-123';

The generated JavaScript may look less readable, but the browser still needs the underlying value to execute the application.

Therefore:

Minification ≠ Encryption
Minification ≠ Secret storage

7. What Can Be Stored in Angular Environment Files?

Values that are safe to expose to the browser can be stored there.

For example:

export const environment = {
  production: true,

  apiUrl: 'https://api.example.com/api',

  applicationName: 'My Application',

  enableLogging: false
};

These are configuration values, not confidential credentials.

Generally acceptable

API base URL
Application name
Public feature flags
Environment name
Non-sensitive UI configuration
Public identifiers

Not acceptable

Database passwords
Connection strings containing credentials
JWT signing keys
Private API keys
OAuth client secrets
Azure credentials
Service account passwords

8. Correct Architecture with ASP.NET Core

Suppose an external payment/service API requires:

API Key = SECRET123

Don't do this:

Angular
   │
   ├── SECRET123 ❌
   │
   ▼
External API

Prefer:

Angular
   │
   │ HTTPS
   ▼
ASP.NET Core API
   │
   │ Retrieves/uses secret
   ▼
Secret Store
   │
   ▼
External API

Angular calls your backend:

this.http.get(
  `${environment.apiUrl}/payments`
);

The ASP.NET Core backend uses the secret when communicating with the external system.

The browser never needs to receive that private credential.

9. What About JWT Tokens?

This requires an important distinction.

A JWT access token issued to the user/client is different from a JWT signing secret/private key.

Angular may legitimately need to send an access token:

Authorization: Bearer <access-token>

But Angular should never contain the server's JWT signing key.

JWT Access Token
      ↓
Issued to client
      ↓
Angular may use it

JWT Signing Secret / Private Key
      ↓
Server-side secret
      ↓
Never put in Angular

How access tokens themselves are stored and protected in browser applications is a separate security design question.

10. What About OAuth Client ID and Client Secret?

These are also different.

A client ID is generally an identifier and may be visible:

export const environment = {
  clientId: 'my-public-client-id'
};

A client secret is confidential:

clientSecret: 'SUPER-SECRET' // ❌

A browser-based Angular SPA is a public client and cannot reliably keep a client secret confidential.

So:

Client ID
   ↓
Can be public

Client Secret
   ↓
Must remain confidential
   ↓
Do not put in Angular

11. Key Points

  • No secret can be securely hidden inside an Angular application delivered to the browser.
  • Angular environment files are configuration files, not secret stores.
  • environment.production.ts is also not secure for secrets.
  • Production builds and minification do not turn secrets into protected values.
  • API URLs can normally be stored in Angular:
apiUrl: 'https://api.example.com/api'
  • Never store:
Passwords
Private API keys
JWT signing secrets
OAuth client secrets
Database credentials
  • Keep secrets in the backend.
  • ASP.NET Core can obtain secrets from server-side configuration or secret-management systems such as Azure Key Vault.
  • A JWT access token and a JWT signing secret are not the same thing.
  • Public client identifiers can be exposed; confidential client secrets cannot.

Interview Questions and Answers

1. Can secrets be securely stored in Angular environment files?

No. Angular runs in the browser, and environment values included in the build can be inspected by users. Environment files should contain only non-sensitive configuration.

2. Is environment.production.ts secure?

No.

Although it is used during the production build, its values can become part of the generated client-side JavaScript.

3. Where should secrets be stored?

Secrets should remain on the server side using mechanisms such as:

ASP.NET Core User Secrets — local development
Environment variables
Azure Key Vault
Other managed secret stores

4. Can an API URL be stored in an Angular environment file?

Yes.

export const environment = {
  apiUrl: 'https://api.example.com/api'
};

An API endpoint is normally not a secret because the browser must know where it sends requests.

5. Can an API key be stored in Angular?

A private API key must not be stored in Angular. If a third-party service requires a confidential API key, Angular should generally call your backend, and the backend should use the private key.

6. Does minification protect Angular secrets?

No.

Minification → Code optimization
Encryption   → Data protection

Minification may make code harder to read, but it does not provide secure secret storage.

7. Can a JWT signing key be stored in Angular?

No. The signing secret/private key must remain on the authentication/backend server.

Angular may receive and send an issued access token, but it must never receive the server's signing key.

8. Can OAuth client secrets be stored in Angular?

No. Angular SPAs are public clients and cannot securely maintain confidential client secrets in browser-delivered code.

9. What is the best short interview answer?

No. Angular environment files cannot securely store secrets because Angular executes on the client and its bundled configuration can be inspected. Environment files should contain only non-sensitive values such as API URLs. Secrets such as private API keys, passwords, JWT signing keys, and client secrets should remain on the ASP.NET Core backend or in a server-side secret store such as Azure Key Vault.

← Back to Article List