Forem: Gorav Singal

CORS & Same-Origin Policy — The Security Rule Every Developer Gets Wrong

Gorav Singal — Tue, 21 Apr 2026 13:41:37 +0000

Your fetch call fails. The console screams:

Access to fetch at 'https://api.example.com' from origin 'https://app.example.com' 
has been blocked by CORS policy.

You Google it. Stack Overflow says add Access-Control-Allow-Origin: *. You do. It works. You move on.

But do you actually know what just happened? And more importantly — did you just open a security hole?

What Is an Origin?

Before we talk CORS, we need to define origin. An origin has three parts:

Part	Example
Protocol	`https://`
Host	`example.com`
Port	`:443`

All three must match for two URLs to be "same-origin."

https://example.com:443/page    ← Reference

https://example.com:443/other   ✅ Same origin (path doesn't matter)
http://example.com:443/page     ❌ Different protocol
https://api.example.com:443     ❌ Different host (subdomains count!)
https://example.com:8080        ❌ Different port

One mismatch in any of the three — and the browser treats it as a completely different origin. No exceptions.

The Same-Origin Policy (SOP)

The Same-Origin Policy is the most fundamental security rule in the browser. Here's what it does:

Blocked by SOP

When JavaScript on origin A tries to read a response from origin B:

fetch() to another domain — response blocked
Reading an <iframe> DOM from another origin — blocked
Accessing window.opener DOM cross-origin — blocked

Allowed Cross-Origin

But SOP doesn't block everything:

<img> tags load cross-origin images — allowed
<script> tags load cross-origin scripts — allowed
<form> submissions go cross-origin — allowed

See the pattern? SOP blocks reading cross-origin responses. It does NOT block sending cross-origin requests.

That gap is exactly what CSRF exploits — and what CORS was built to solve.

Why CORS Exists

Modern web apps don't live on a single origin:

Frontend  →  app.example.com
API       →  api.example.com
CDN       →  cdn.example.com

Three different origins. All blocked by SOP. If SOP blocked everything, the modern web wouldn't work.

CORS (Cross-Origin Resource Sharing) is the controlled exception. It's a protocol that lets the server say:

"I trust this specific origin. Let their JavaScript read my response."

The server opts in. The browser enforces it.

How Simple CORS Works

For simple requests — GET, HEAD, or POST with basic headers — no preflight is needed.

Step 1: Browser sends the request with an Origin header:

GET /api/data HTTP/1.1
Host: api.example.com
Origin: https://app.example.com

Step 2: Server responds with Access-Control-Allow-Origin:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://app.example.com
Content-Type: application/json

Browser checks: does Origin match Access-Control-Allow-Origin?

Match → JavaScript can read the response
No match or missing → Browser blocks it. CORS error.

The request still went through. The server still processed it. But your code can't see the result.

Preflight Requests

Not all requests are simple. When you use:

PUT, DELETE, or PATCH
Custom headers like Authorization
Content-Type: application/json

The browser sends an OPTIONS request first — the preflight:

OPTIONS /api/data HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Authorization, Content-Type

Server responds with what it allows:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 86400

If everything checks out, then the browser sends the actual PUT request. Two round trips instead of one — but the server explicitly opted in to every method and header.

Max-Age: 86400 caches the preflight for 24 hours so subsequent requests skip the OPTIONS call.

3 Dangerous CORS Misconfigurations

This is where developers get burned.

1. Wildcard Origin

Access-Control-Allow-Origin: *

Any website can read your API responses. For a truly public API with no auth — maybe fine. But * cannot be used with credentials (Access-Control-Allow-Credentials: true). The browser explicitly forbids it.

2. Reflecting the Origin (The Dangerous One)

// Server code — DON'T DO THIS
res.setHeader('Access-Control-Allow-Origin', req.headers.origin);
res.setHeader('Access-Control-Allow-Credentials', 'true');

Whatever origin the request comes from, the server echoes it back. evil.com sends a request? Server responds with Allow-Origin: evil.com. With credentials enabled.

That's a full CORS bypass. The attacker's page can now read authenticated responses from your API.

3. Trusting Null Origin

Access-Control-Allow-Origin: null

Sandboxed iframes and file:// requests send Origin: null. If your server trusts null, an attacker can craft a sandboxed iframe that makes authenticated requests to your API.

The Fix: Explicit Allowlist

const ALLOWED_ORIGINS = [
  'https://app.example.com',
  'https://admin.example.com',
];

app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (ALLOWED_ORIGINS.includes(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Credentials', 'true');
  }
  next();
});

Three rules:

Use an explicit allowlist of trusted origins
Never reflect the Origin header blindly
Never trust null

TL;DR

Concept	One-liner
Origin	Protocol + Host + Port — all three must match
SOP	Browser blocks JS from reading cross-origin responses
CORS	Server opts in with `Access-Control-Allow-Origin`
Simple request	GET/POST with basic headers — goes straight through
Preflight	OPTIONS check before complex requests
Wildcard	`*` works for public APIs, forbidden with credentials
Reflected origin	Echoing back any origin = full CORS bypass
Null origin	Sandboxed iframes exploit this — never trust it

Watch the Full Video

I made an animated video walking through all of this with visual diagrams — origins breaking apart, requests flowing between browser and server, preflight handshakes, and attack scenarios.

This is part of my Web Security series on GyanByte. Previous episodes covered Authentication, Authorization, XSS, and CSRF.

Next up: Content Security Policy (CSP) — the header that controls what your page can load, run, and connect to.

Have you been burned by a CORS misconfiguration? Drop your war story in the comments.

Secrets Management — Vault, SSM, and Secrets Manager Compared

Gorav Singal — Tue, 14 Apr 2026 12:14:15 +0000

I've watched a production database get wiped because someone committed a root password to a public GitHub repo. It took less than twelve minutes from push to compromise. Automated bots scan every public commit for secrets — and they find them constantly.

If secrets management isn't the first security problem you solve, nothing else matters. Here's a condensed comparison of the three tools I reach for in practice.

The Problem

A "secret" is any credential your app needs at runtime but should never be visible in source code, logs, or config files — database passwords, API keys, TLS certs, OAuth tokens.

The naive approach (env vars, config files in version control) fails because:

Git history is forever — deleting a secret in a later commit doesn't remove it from history
Env vars leak — process listings, crash dumps, and logging frameworks routinely expose them
No rotation — baked-in secrets mean redeploying everything to rotate
No audit trail — you can't tell who accessed what and when

The Three Tools

1. SSM Parameter Store

The simplest option. A key-value store baked into AWS with native IAM integration.

aws ssm put-parameter \
  --name "/prod/myapp/db-password" \
  --value "s3cureP@ssw0rd!" \
  --type SecureString \
  --key-id "alias/myapp-key"

The hierarchical naming (/prod/myapp/db-password) maps directly to IAM policies — grant access to /prod/myapp/* without exposing /prod/billing/*.

Use when: Simple config and secrets that don't need auto-rotation. Free standard tier covers most teams (up to 10,000 parameters).

2. AWS Secrets Manager

The killer feature is built-in automatic rotation via Lambda, plus first-class RDS/Redshift/DocumentDB support.

The rotation flow: a Lambda creates a new credential, sets it as pending, tests it, then promotes it to current. If any step fails, the current secret stays untouched.

Use when: Database credentials needing auto-rotation, versioned secrets, cross-account sharing. $0.40/secret/month.

3. HashiCorp Vault

Vault isn't just a secrets store — it's a secrets engine. It generates short-lived, on-demand credentials for databases, cloud providers, PKI, and SSH.

# Get a dynamic credential (valid for 1 hour)
vault read database/creds/myapp-readonly

Every call creates a brand-new database user with a unique password. When the TTL expires, Vault revokes it automatically. No rotation needed — credentials are ephemeral by design.

Use when: Multi-cloud environments, dynamic credentials, PKI management, encryption-as-a-service. The tradeoff is operational complexity.

Quick Comparison

Dimension	SSM Parameter Store	Secrets Manager	HashiCorp Vault
Cost	Free (standard)	$0.40/secret/month	Self-hosted or HCP
Auto-Rotation	Manual only	Built-in (Lambda)	Dynamic secrets
Multi-Cloud	AWS only	AWS only	Any cloud + on-prem
Dynamic Secrets	No	No	Yes
Complexity	Low	Medium	High

My rule of thumb: Start with SSM. Graduate to Secrets Manager when you need rotation. Move to Vault when you need multi-cloud or dynamic secrets.

Common Pitfalls

Secrets in env vars logged to stdout — frameworks like Express, Django, and Spring dump env vars in error pages. Use a secrets SDK instead.
No caching layer — calling Secrets Manager on every request adds 5-15ms latency and costs money. Cache with a 5-minute TTL.
Terraform state with plaintext secrets — aws_secretsmanager_secret_version stores values in plaintext in state. Encrypt your state backend (S3 + KMS).
Overly broad IAM policies — ssm:GetParameter on * means every Lambda reads every secret. Scope to specific paths.
No secret scanning in CI/CD — tools like gitleaks or GitHub's built-in scanning should be mandatory. The twelve-minute push-to-compromise window is real.

Key Takeaways

Never hardcode secrets — not in code, config, Docker images, or logged env vars
Encrypt at rest (KMS) and in transit (TLS), no exceptions
Cache aggressively to balance freshness against latency
Audit everything — if you can't answer "who accessed this at 3am Tuesday," it's incomplete
Rotate or go ephemeral — long-lived, never-rotated secrets are ticking time bombs

This is a condensed version. For the full article with complete code examples (Python, Node.js, Terraform), rotation Lambda patterns, and detailed implementation walkthroughs, read the full post on gyanbyte.com.

ReactJS - How to restrict data type for different kind of data

Gorav Singal — Sun, 05 Jul 2020 16:46:31 +0000

Introduction

Javascript is not a strict type language. We can use a variable to save any kind of data. Whether its a string or integer or boolean or object. Well, this gives aa flexibility in using the variabales. But, it brings some complexity of making sure that the data is of certain expected type only.

For example, you are showing data of students as:

Id
Name
Image
Age

Example reactjs component:

import React, { Component } from "react";

const Student = ({ name, age, img }) => {
  return (
    <article>
      <img src={img} alt="student" />
      <h5>name : {name}</h5>
      <h5>age : {age}</h5>
    </article>
  );
};

class StudentList extends Component {
  state = {
    students: [
      {
        id: 1,
        img: "some img path",
        name: "Raman",
        age: 21
      },
      {
        id: 2,
        img: "Some image path",
        name: "Rahul",
        age: 22
      }
    ]
  };
  render() {
    return (
      <section>
        {this.state.students.map(student => (
          <Student
            key={student.id}
            img={student.img}
            name={student.name}
            age={student.age}
          />
        ))}
      </section>
    );
  }
}

class App extends Component {
  render() {
    return <StudentList />;
  }
}

export default App;

If you messed up somewhere in your data. You might ends up showing age in place of name, or name in place of age. Since, there will be no error or warning unless you are doing some special operation with that variable.

Lets discuss abaout making our type strict.

Prop Types

There is a npm module for this purpose: prop-types. To install this module:

npm install prop-types

How to use

Lets see the modified component:

import React, { Component } from "react";
import PropTypes from "prop-types";

const Student = ({ name, age, img }) => {
  return (
    <article>
      <img src={img} alt="student" />
      <h5>name : {name}</h5>
      <h5>age : {age}</h5>
    </article>
  );
};
Student.propTypes = {
  name: PropTypes.string,
  age: PropTypes.number,
  img: PropTypes.string
};

class StudentList extends Component {
  state = {
    students: [
      {
        id: 1,
        img: "some img path",
        name: "Raman",
        age: 21
      },
      {
        id: 2,
        img: "Some image path",
        name: "Rahul",
        age: 22
      }
    ]
  };
  render() {
    return (
      <section>
        {this.state.students.map(student => (
          <Student
            key={student.id}
            img={student.img}
            name={student.name}
            age={student.age}
          />
        ))}
      </section>
    );
  }
}

class App extends Component {
  render() {
    return <StudentList />;
  }
}

export default App;

Notice the usage of propTypes as:

Student.propTypes

We are declaring the data types of certain type of data. And, if we try to provide any other kind of data to such variables, react will complain. It will throw errors. And you will come to know the mistakes.

How to restrict data to be Required (Not Null)

In many scenarios we would require that the data not be null. With prop-types you can specify or restrict with some attributes that this particular data must be present.

Lets see how to do this:

Student.propTypes = {
  name: PropTypes.string.isRequired,
  age: PropTypes.number.isRequired,
  img: PropTypes.string
};

Note: Above code will work if you are receiving your values as individual fields. If you are receiving the object, above code will not work. For objects, we have a slightly different way:

Student.propTypes = {
  student: PropTypes.shape({
    name: PropTypes.string.isRequired,
    age: PropTypes.number.isRequired,
    img: PropTypes.string
  })
};

In above code, we have decided that name and age must be present. If our data does not have these fields, then we will get errors.

Also see How to create ReactJS Components

How to configure default properties

In many cases, our data does not have some of the attributes. Example: Image is not there. And we would want to declare some default values. It means, if our data does not have any value for particular attribute, please use this default value.

Student.defaultProps = {
  img: "some default image path"
};

prop-types does not support Objects for default values.

Originally posted at: ReactJS - How to restrict data type for different kind of data