13 — RAG and Backend Security — Grounding Models, Hardening the Stack

A cluster that pairs RAG with a run of security nodes — OWASP, HTTPS, SSL/TLS, CORS, server security, CSP — looked random to me until two ideas clicked: RAG grounds an LLM in real data so its answers aren't hallucinated, and the security cluster is one principle repeated at every layer of the stack — defend in depth. [1][5] Putting them together, the thread is trust — RAG is about what the model can trust as context, security is about what the server can trust as a request.

The frame that helped is that both halves are responses to untrustworthy inputs. An LLM trained on the open internet will confidently invent facts; RAG fixes that by retrieving real documents and injecting them into the prompt so the model has something grounded to answer from. A backend exposed to the open internet will receive malicious requests; the security stack fixes that with encryption (HTTPS/TLS), browser policy (CORS, CSP), app-layer defenses (OWASP), and OS hardening. Neither problem has one solution; both are solved in layers.

RAG: retrieve, then generate

Retrieval-Augmented Generation (RAG) combines information retrieval with language generation: instead of letting the model answer from its training data alone, first retrieve relevant documents from a knowledge base, then generate the answer with those documents in the prompt [2]. The model's output is grounded in the retrieved context rather than in whatever it memorized during training.

The pipeline is the embedding fundamentals from the previous post, operationalized:

1. Index. Take the knowledge base (docs, internal wiki, codebase), chunk it into passages, embed each chunk into a vector, store the vectors in a vector database.
2. Retrieve. At query time, embed the user's question, search the vector DB for the nearest few passages (the ones most semantically similar to the query).
3. Generate. Construct a prompt containing the retrieved passages plus the question, and let the LLM generate an answer citing them.

The payoff is that the model answers from current, specific, verifiable sources instead of its training memory. A RAG system answering "what's our refund policy?" retrieves the actual policy doc; a pure LLM guesses based on policies it saw during training, which is almost certainly wrong for your company. RAG also makes the model's claims checkable — I can point at the retrieved chunk the answer came from.

The failure mode to know: RAG only helps if retrieval finds the right passages. If the vector search returns irrelevant chunks, the model generates from bad context and the answer is still wrong, just confidently. Garbage in, garbage out — the retrieval step is where most RAG quality is won or lost, not the model.

The security cluster, in layers

The security nodes the roadmap lists are one principle applied at different layers: never trust input, defend at every boundary. Walking from the network up:

HTTPS and SSL/TLS: encrypt the transport

HTTPS is HTTP wrapped in TLS, providing confidentiality (nobody can read the traffic), integrity (nobody can tamper undetected), and authenticity (the server is who it claims) [3]. SSL/TLS are the cryptographic protocols that do the encryption — SSL is the deprecated predecessor, TLS is the modern secure version [4]. The padlock in the browser means the conversation is encrypted; the certificate proves the server's identity.

From the backend side, HTTPS is non-negotiable for any traffic carrying credentials, personal data, or anything sensitive. The practical work is terminating TLS at the web server (Nginx, Caddy) or via a managed platform, with certificates from Let's Encrypt (free, automated) or a commercial CA. There's no scenario in 2026 where shipping plain HTTP to users is acceptable.

CORS: the browser-boundary defense

CORS (Cross-Origin Resource Sharing) is a browser-enforced mechanism that controls which origins a web page can make requests to [6]. The same-origin policy says a page from a.com can't read responses from b.com by default; CORS is the opt-in — the server at b.com sends headers (Access-Control-Allow-Origin) telling the browser which foreign origins are allowed.

The thing that took me a while to internalize: CORS is enforced by the browser, not the server. The server sends the headers; the browser decides whether to let the page read the response. This is why a CORS error shows up in the browser console, not the server logs — the request reached the server, the server responded, and the browser blocked the page from reading it. The fix is always a header on the server's response, configured to allow the specific origins that should be trusted.

The security implication: CORS exists to protect users, not servers. A misconfigured Access-Control-Allow-Origin: * on an authenticated endpoint can let any website make requests on a logged-in user's behalf. The rule is to allow only the specific origins I trust, never the wildcard for credentialed requests.

CSP: the document-level defense

Content Security Policy (CSP) is a defense against XSS and code injection, implemented via an HTTP header that declares which sources of content (scripts, styles, images, fonts) the browser is allowed to execute or load [7]. A strict CSP like script-src 'self' tells the browser: only run scripts from my own origin — refuse inline scripts, refuse third-party CDNs, refuse anything else.

The problem CSP solves is XSS — when an attacker injects a <script> tag into a page, the browser would normally execute it. With a strict CSP, the injected script (which is inline or from an unapproved origin) is refused. CSP is the last line of defense when input validation fails — and input validation always fails eventually.

OWASP: the app-layer defense

OWASP (Open Web Application Security Project) is the community that publishes the Top 10 — the consensus list of the most critical web application security risks, updated every few years [8]. The Top 10 includes injection (SQL, command), broken authentication, sensitive data exposure, XSS, broken access control, and more. The OWASP cheat sheets document concrete defenses for each.

The reason to know OWASP isn't to memorize the list; it's to have a checklist for the common attacks. When I'm reviewing an endpoint, the Top 10 is the set of questions I ask: am I parameterizing SQL? Am I validating input? Am I enforcing authorization on every resource? Am I hashing passwords? Am I escaping output? The Top 10 is the failure modes that find every backend; treating it as a review checklist is how I catch them before an attacker does.

Server security: the OS-layer defense

Server hardening is the OS-level defenses — patch management, firewall rules, disabling unused services, SSH key-only auth, least-privilege user accounts, regular backups, intrusion detection [9]. The principle is the same as everywhere else: reduce the attack surface, then defend what remains. A server running only the services it needs, patched promptly, accessible only from the IPs that need access, is a dramatically smaller target than a default-configured box.

The unifying principle: defense in depth

Every layer above — transport (HTTPS), browser boundary (CORS), document (CSP), application (OWASP), operating system (hardening) — is a separate defense. None is sufficient alone. The principle is defense in depth: assume any single layer will fail, and ensure the next layer still holds. XSS slips past input validation? CSP blocks the script. An attacker steals a session cookie over HTTP? HTTPS would have prevented the theft. A vulnerability in my framework? The principle of least privilege limits the damage.

How I use this

The RAG half and the security half each reduce to a habit. For RAG: I treat retrieval quality as the project, not the model — if the answer is wrong, I check what was retrieved before I blame the model, because the model can only work with the context it was given. For security: I treat the OWASP Top 10 as a release checklist, run HTTPS everywhere with no exceptions, configure CORS to allow only specific trusted origins (never * with credentials), set a strict CSP, and harden the OS. None of these layers is optional, and none is sufficient — the discipline is doing all of them, every time, because the attacker only needs one gap and I'm defending every layer at once.

The framing that ties the cluster together — RAG grounds the model, the stack defends the server, both are about trust in layers — is what keeps me from treating security as a separate phase. It's not a thing I do at the end; it's a property of every decision at every layer, the same way RAG's retrieval quality is a property of every chunk I index.

References

[1] IBM, "AI in software development," 2024. [Online]. Available: https://www.ibm.com/think/topics/ai-in-software-development

[2] Google Cloud, "What is Retrieval-Augmented Generation?," 2024. [Online]. Available: https://cloud.google.com/use-cases/retrieval-augmented-generation

[3] Cloudflare, "What is HTTPS?," 2024. [Online]. Available: https://www.cloudflare.com/en-gb/learning/ssl/what-is-https/

[4] "Transport Layer Security," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/Transport_Layer_Security

[5] OWASP, "OWASP Top 10 Security Risks." [Online]. Available: https://cheatsheetseries.owasp.org/IndexTopTen.html

[6] Mozilla, "Cross-Origin Resource Sharing (CORS)," MDN Web Docs. [Online]. Available: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

[7] Mozilla, "Content Security Policy (CSP)," MDN Web Docs. [Online]. Available: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

[8] OWASP, "The OWASP Foundation." [Online]. Available: https://owasp.org/

[9] Sophos, "What is a hardened server?." [Online]. Available: https://www.sophos.com/en-us/cybersecurity-explained/what-is-server-hardening