Same-origin policy

02Three parts

Use the effective scheme, host, and port together. For http, an omitted port means 80; for https, it means 443. Thus an omitted default and an explicitly written default refer to the same port. A changed scheme or changed port makes an origin different even if the host matches.

For HTTP URLs, paths, queries, and fragments are outside the origin comparison. The fragment is the part after # used to identify a location within a resource. Two different paths under the same scheme, host, and port stay in one origin.

A file URL reads a local resource and does not follow the same simple web-origin model. Browsers may give local files opaque origins, identities that do not behave like a shared HTTP host and port. Do not assume nearby files share permissions. The printed file URL supplies a different kind of access from http://127.0.0.1:9000; no browser-specific local-file behavior is claimed.

Servers can deliberately allow some cross-origin response sharing through Cross-Origin Resource Sharing, or CORS, a browser mechanism based on response headers. That allowance is separate from authenticating an account and authorizing access. curl is outside the browser’s same-origin restrictions, which is another reason server checks remain necessary.

03Sort three pairs

Use the three fresh pairs on the origin cards. The outcome card is fictional evidence for the basic policy case, with no special cross-origin sharing permission. Decide from the three URL parts before reading those outcomes.

Original fictional pairs. No browser compared them.
For these HTTP URLs, an origin is scheme, host, and effective port.
Effective means the printed port, or the scheme’s default when omitted.
The path is outside that triple.

Worked pair
http://127.0.0.1:7000/one
http://127.0.0.1:7443/one
Scheme and host match. Ports 7000 and 7443 differ.

Activity pairs
Pair 1
http://127.0.0.1:9000/notes
http://127.0.0.1:9000/other
The path differs. Scheme, host, and port match.

Pair 2
http://127.0.0.1:9000/notes
http://127.0.0.1:9001/notes
The port differs.

Pair 3
https://127.0.0.1:9000/notes
http://127.0.0.1:9000/notes
The scheme differs. Both lines print port 9000. The schemes still differ, so the origins differ.

Check: pair 1 is the same origin.

Original fictional browser outcomes for the activity pairs.
Assume no special cross-origin sharing permission in these basic cases.

Pair 1: a script on the first page read the second page's text.
Pair 2: the read was blocked.
Pair 3: the read was blocked.

A form on the first page of pair 2 can still name the other port as its target.
Sending that form is a different fact from reading the response.
curl is a client outside this browser policy.
The server still decides who may read the stored row.

file:///home/desk/lab-site/note.txt
This is a file URL. It is a different reference from the origin http://127.0.0.1:9000.
Local files may have opaque origins; this card makes no browser-specific permission claim.

1. For each URL, write scheme, host, and effective port. Keep its path in a separate column so it cannot accidentally decide the origin.
2. In pair 1, compare matching http, 127.0.0.1, and 9000. Its paths differ but its origin matches. Pair 2 changes the port; pair 3 changes the scheme.
3. Compare with the fictional outcomes: pair 1’s read succeeds and the other reads are blocked. State that these are model outcomes, not a browser run.
4. Explain why a form targeting another origin can still be sent in this ordinary case even when a script’s response read is blocked. Stop without opening any target or changing browser settings.

04Names and requests case

Finish the module and stage with the separate names-and-requests case. It combines DNS, HTTP, a form, session state, and origin comparison. Use its seven-line rubric to review an evidence note, while keeping the named DNS example distinct from the loopback request.

Names and requests case. Original fiction. Self-review activity.
No query, request, or browser comparison was performed.

Name
shelf.lab.invalid
A record: 192.0.2.44
This case has no AAAA line.
The later loopback request is separate; no resolution from this name
to the loopback address is shown.

Request
GET /note HTTP/1.1
Host: 127.0.0.1:8000
Status: 200
Body word: kept

Form
Label: Note
name attribute: slip
Predicted urlencoded body: slip=kept

Session
Cookie identifier: lab-sid-04
Stored role on the server: member
The decision that reads the row sits on the server.

Guided origin comparison, reusing pair 1 from origin-cards.txt
http://127.0.0.1:9000/notes
http://127.0.0.1:9000/other
The scheme, host, and port match. These paths share one origin.
The server still enforces the stored row.

Independent URL evidence for the later question
http://127.0.0.1:8000/note
http://127.0.0.1:8001/note
Leave this comparison for the question; no conclusion is supplied here.

File URL
file:///home/desk/lab-site/note.txt
Opening that file reads text on disk.
It is a different reference from the HTTP origin http://127.0.0.1:8000.

Rubric for notes
1. The IPv4 on the A record is 192.0.2.44.
2. The method is GET and the status is 200.
3. The submitted key is slip, taken from the name attribute.
4. The session decision uses the server's stored role, member.
5. In the guided 9000 pair, the three origin components match; paths do not decide the comparison.
6. A blocked browser read leaves the server's own check in place.
7. The file URL is a different kind of reference from that HTTP origin.

1. Record the fictional A-record address for shelf.lab.invalid. Separately record the request to the loopback host, its method GET, status 200, and body word kept. The card does not show a DNS connection between those two hosts.
2. Read the form’s name attribute slip and predict slip=kept. Then identify session identifier lab-sid-04 and stored role member as different values.
3. For the synthesis origin reasoning, reuse pair 1 on port 9000: /notes and /other share the scheme, host, and port despite different paths. Explain why that browser comparison does not replace the server’s trusted-state check. Keep the separate 8000/8001 URL evidence for the question.
4. Distinguish the local file URL from the HTTP URL. Review your note against all seven rubric lines and stop. You have traced the supplied model; a real DNS query, page load, certificate check, or form submission would need separate observation.

05Optional challenge

For about ten extra minutes, explain why a blocked script read is insufficient protection for a state-changing action. Your answer should say that some requests can still be sent, that a request is different from reading its response, and that the server needs its own checks. No cross-origin request is required.

06Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Base: https://panel.grove.invalid/one
P: https://panel.grove.invalid:443/two?x=1
Q: https://panel.grove.invalid:8443/one
R: http://panel.grove.invalid/one
S: https://other.grove.invalid/one
For https, omitted port means 443. For http, omitted port means 80. Paths and queries are not origin components.

Page script from https://panel.grove.invalid sends an allowed request to https://archive.grove.invalid. The request reaches the server. No CORS permission is present. The browser blocks this script from reading the response. The server receives a state-changing request and must enforce its own permission rules.

07Explain your prediction

Optional written self-check: Compare scheme, host and effective port explicitly. Keep request sending, browser response reading and server authorization as separate decisions, and limit the simple origin model to the HTTP URLs supplied.