DEV Community: Marco

I made my portfolio site audit its own security headers, live, in front of you

Marco — Wed, 22 Jul 2026 09:27:30 +0000

My portfolio has a section that runs curl -I on itself while you watch. Not a screenshot of headers I pasted in last year and forgot to update. The page fetches its own URL, reads the response headers off it, and prints each one ON or missing, right there in the section. If I ever ship a build that drops a header, the page snitches on me the next time someone loads it.

I want to walk through how it works, and then the part that made me rewrite it: the real Content-Security-Policy is not in one place. It is split across two. Showing only the header would have told half the truth, on a page whose whole point is not doing that.

The setup

The site is built with Astro, output fully static, served from Cloudflare. There is a section on the page titled like a shell command. Under it, a list of the security headers I expect the edge to send. The expected list is not hardcoded into the script, it comes from the component:

const expected = [
  'Content-Security-Policy',
  'Strict-Transport-Security',
  'X-Content-Type-Options',
  'Referrer-Policy',
  'Permissions-Policy',
];

Same origin, so the browser is allowed to read the response headers back. That is the whole trick. A fetch to any other site would get its headers hidden by CORS, but a page is allowed to look at itself.

What I actually built

The client script does a HEAD request to the current URL and reads the headers off the response:

fetch(window.location.href, { method: 'HEAD' })
  .then((res) => {
    box.replaceChildren();
    expected.forEach((name) => box.appendChild(row(name, res.headers.get(name))));
    box.appendChild(row('Content-Security-Policy (meta)', metaCsp && foldHashes(metaCsp)));
  })

HEAD, not GET, because I only care about the headers and there is no reason to pull the body again. For each expected header it calls res.headers.get(name). If the value is there, the row renders ON and prints it. If it is null, the row goes missing and gets a different style. No allowlist of "good" values, no grading. It shows what came back.

One detail I care about more than it probably deserves: every cell is built with document.createElement and textContent, never innerHTML. This is a section about security headers. If I XSS my own security section by piping a header value straight into the DOM as HTML, I have earned every bit of the embarrassment. So the header values are text, and text only.

The site also scored A+ on Mozilla's HTTP Observatory, and the hero links straight to that scan so you can re-run it yourself instead of taking my word for the badge. The live card and the external scanner are checking the same thing from two sides.

The catch: the CSP is in two places

Here is where it got interesting, and where I had to go back and change the card.

When I first wrote it, the card read the five headers off the response and stopped. Clean, done. Except the Content-Security-Policy that actually protects the page is not fully in that header. Astro hashes its own bundled scripts and styles at build time and writes them into a <meta http-equiv> CSP. It can only do that at build, because that is when it knows the hashes. So the meaningful part of my policy, the script-src full of sha256- hashes, lives in the HTML, not in the header the card was reading.

Why not just put the whole CSP in the Cloudflare _headers file and be done? Because then the browser applies both policies as an intersection, and they fight. My _headers file says exactly this, in a comment I left for future me:

# La CSP non sta qui: la genera Astro (`security.csp` in astro.config.mjs) come
# <meta http-equiv>, perché solo in build può calcolare gli hash dei propri script.
# Se una CSP vivesse anche qui, le due policy verrebbero applicate entrambe come
# intersezione: un `script-src 'self'` in questo file annullerebbe gli hash del meta
# e rimetterebbe il sito offline.

A script-src 'self' in the header would intersect with the hash-based script-src in the meta, and the result blocks the very scripts the hashes were meant to allow. Site offline.

So there is exactly one CSP directive that has to live in the header, and it is the one a <meta> tag is not allowed to express: frame-ancestors. Per spec, frame-ancestors inside a <meta> is ignored, so it has to be a real response header. That is the whole content of the CSP header at the edge:

Content-Security-Policy: frame-ancestors 'none'
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Which means my original card, reading only headers, would have proudly printed a Content-Security-Policy of frame-ancestors 'none' and called it a day. Technically true. Also a lie by omission, because it hid the part of the policy that does most of the work.

So the card reads the meta too. It pulls the <meta http-equiv="content-security-policy"> content out of the DOM and prints it as a second CSP row. The hash list is dozens of entries long and useless to look at, so it folds each run of hashes into a count:

const foldHashes = (csp) =>
  csp.replace(/(?:'sha\d{3}-[A-Za-z0-9+/=]+'\s*)+/g, (run) => {
    const n = run.match(/'sha\d{3}-/g)?.length ?? 0;
    return `${n} hash `;
  });

The count is read from the real policy on the page, not a number I typed. If Astro emits one more inline style tomorrow, the number goes up on its own.

What this cost me, honestly

I am mid-level. I did not know going in that frame-ancestors was meta-blind, or that two CSPs intersect instead of one winning. I learned both by breaking the site. There is a manual hash in my Astro config for one inline script, the anti-flash theme script that runs before first paint, because Astro leaves is:inline scripts alone and will not hash them for me:

scriptDirective: {
  resources: ["'self'", 'https://challenges.cloudflare.com'],
  hashes: ['sha256-WV81hIAeXjEdgj/cFIXtOf53g8pIquCjmXQuCHOehlw='],
},

If I touch that script and forget the hash, npm run test:csp fails and tells me the new hash to paste. That test exists because I shipped the mismatch once and the theme script got blocked in production.

The card is not clever. It is a HEAD request, five .get() calls, and one querySelector. What I like about it is that it cannot drift. A README claiming "we set strict security headers" ages the moment someone edits a config. This section re-derives the claim from the live response every time the page loads, and it reads both halves of a policy that lives in two files, because reading one half would make the page a small liar about the one topic it is supposedly honest about.

If you want to try the pattern: same-origin HEAD, read the headers, read the meta CSP too if you have one, build the DOM with textContent. That is the entire thing.

From text-JSON parsing to Claude tool use in JobSearch

Marco — Tue, 21 Jul 2026 00:55:05 +0000

My job-search tool had five functions whose only purpose was fixing JSON that Claude had just written. _clean_json_text, _fix_unescaped_newlines, _fix_single_quotes, _strip_markdown_wrapper, _extract_and_parse_json. There was also a sixth, _retry_json_fix, which took the broken JSON and sent it back to the model with a polite request to fix its own mess. I wrote every one of them, one bug at a time, over weeks. I was a little proud of them.

That was the problem.

How you end up with five parsers

JobSearch is my personal tool, in production, single user: me. It ingests job offers from nine boards, and when I press "Analyze", Claude reads the offer against my CV and returns a structured verdict: score, recommendation, career track, the English level the ad actually requires. That verdict has to be JSON, because everything downstream is a database row, not prose.

The first version did what every tutorial does. Ask the model for JSON in the prompt, take response.content[0].text, run json.loads on it. It worked in the demo and then production started teaching me things.

The model wrapped the JSON in markdown fences, so I wrote a function to strip them. Sometimes it used single quotes, so I wrote a function to fix those. Then a description with a line break inside a string, so I wrote _fix_unescaped_newlines. Then a NaN where a number should be. Every fix was five lines, obviously correct, and came with its own tests. I still have the test names in the git history and they read like a confession: test_removes_trailing_commas, test_replaces_nan_with_null, test_replaces_infinity, test_unclosed_fence_still_strips_opening.

By April the parsing layer was around 250 lines with seven strategies, chained, each catching what the previous one let through. The last resort was the AI self-repair call: if nothing parsed, send the broken output back and ask the model to repair it. A second API call, with real latency and real cost, to fix a formatting problem the first call should never have had.

I had a test suite asserting that my code could survive output nobody should ever have produced. That is not robustness. That is a bug report addressed to the wrong recipient.

The actual fix

Anthropic's API has tool use. You normally reach for it to let the model call your functions. But it has a stricter reading: if you define exactly one tool whose input schema is the shape of the answer you want, and you force it with tool_choice, the model cannot answer any other way. The JSON arrives already parsed, validated against the schema by the API itself, as a Python dict on the response object.

I already had a Pydantic model for the analysis, because the DB row needed one. So the schema was free:

def _schema_from_model(model_cls: type[BaseModel]) -> dict[str, Any]:
    """Produce a JSON Schema from a Pydantic model, suitable for input_schema."""
    ...

response = client.messages.create(
    model=model_id,
    system=system,
    messages=[{"role": "user", "content": user}],
    tools=[{
        "name": "submit_analysis",
        "description": "Return the structured job analysis.",
        "input_schema": _schema_from_model(JobAnalysis),
    }],
    tool_choice={"type": "tool", "name": "submit_analysis"},
)
block = next(b for b in response.content if b.type == "tool_use")
data = block.input  # a dict, parsed by the SDK, no text in sight

The refactor landed on April 14 as one commit: every AI call in the codebase migrated, all five parsers deleted, the self-repair fallback deleted, the garbage-JSON test file deleted with them. The commit message says minus 200 lines and it undersells it, because the lines that left were the ones I had to re-read every time something broke.

It was the scary PR of the batch. I shipped it in the middle of an afternoon where Claude and I pushed thirteen PRs to production, and I wrote about that day separately. Twelve of those PRs were routine. This one deleted a safety net and replaced it with a promise from an API, in the same diff.

One thing I kept: the Pydantic validation after the call. The schema guarantees shape, not sense. A score of 950 on a 0-100 field is schema-valid JSON and still garbage, and model output stays untrusted input no matter how it is delivered. The contract moved into the API; the checking stayed on my side of it.

The surprise came after launch

Here is the part I did not expect, and the reason this piece is not just "use tool use, delete your parsers".

With text output, the model treated my prompt rules a bit loosely, and the parsing chaos hid it. With a forced schema, it obeys much more literally. I had a fallback rule for freelance positions: Italian job ads sometimes want a P.IVA, a VAT number, which changes whether the offer makes sense for me at all. The rule said, roughly, "if freelance status is ambiguous, flag it". Under tool use the model started flagging offers that mentioned freelancing in passing, a line about contractors in another team, anything. Ambiguous had quietly meant "mentioned anywhere".

The schema made the model more obedient, and the obedience exposed how sloppy my instructions had been. The fix was not code. It was rewriting the prompt with explicit precedence: the contract type stated in the offer wins, the fallback fires only when the offer itself is about the contract and does not settle it.

So the lesson I actually paid for: when you migrate from text parsing to tool use, your interpretive prompt rules need to be tightened, not loosened. The model stops improvising on format and starts taking your words seriously. If your rules were vague, you find out now.

What I would tell past me

The parsers were never defensive programming. They were a symptom that the contract lived on the wrong side of the API call, and every new repair function was me renegotiating that contract in the worst possible place, after the response, one edge case at a time.

If your pipeline has a function called _fix_single_quotes, you do not need a better parser. Move the shape into input_schema, force the tool, keep your validation, and delete the museum. Then go re-read your prompt, because the model is about to start believing every word of it.

"I made my portfolio site audit its own security headers, live, in front of you"

Marco — Wed, 15 Jul 2026 14:13:30 +0000

The setup

const expected = [
  'Content-Security-Policy',
  'Strict-Transport-Security',
  'X-Content-Type-Options',
  'Referrer-Policy',
  'Permissions-Policy',
];

What I actually built

The client script does a HEAD request to the current URL and reads the headers off the response:

fetch(window.location.href, { method: 'HEAD' })
  .then((res) => {
    box.replaceChildren();
    expected.forEach((name) => box.appendChild(row(name, res.headers.get(name))));
    box.appendChild(row('Content-Security-Policy (meta)', metaCsp && foldHashes(metaCsp)));
  })

The catch: the CSP is in two places

Here is where it got interesting, and where I had to go back and change the card.

# La CSP non sta qui: la genera Astro (security.csp in astro.config.mjs) come
# <meta http-equiv>, perché solo in build può calcolare gli hash dei propri script.
# Se una CSP vivesse anche qui, le due policy verrebbero applicate entrambe come
# intersezione: un script-src 'self' in questo file annullerebbe gli hash del meta
# e rimetterebbe il sito offline.

A script-src 'self' in the header would intersect with the hash-based script-src in the meta, and the result blocks the very scripts the hashes were meant to allow. Site offline.

Content-Security-Policy: frame-ancestors 'none'
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

const foldHashes = (csp) =>
  csp.replace(/(?:'sha\d{3}-[A-Za-z0-9+/=]+'\s*)+/g, (run) => {
    const n = run.match(/'sha\d{3}-/g)?.length ?? 0;
    return `${n} hash `;
  });

The count is read from the real policy on the page, not a number I typed. If Astro emits one more inline style tomorrow, the number goes up on its own.

What this cost me, honestly

scriptDirective: {
  resources: ["'self'", 'https://challenges.cloudflare.com'],
  hashes: ['sha256-WV81hIAeXjEdgj/cFIXtOf53g8pIquCjmXQuCHOehlw='],
},

If you want to try the pattern: same-origin HEAD, read the headers, read the meta CSP too if you have one, build the DOM with textContent. That is the entire thing.

How I shipped 13 PRs in one afternoon pair-programming with Claude (and what I learned)

Marco — Wed, 15 Apr 2026 10:05:39 +0000

Last week I was rebuilding parts of JobSearch — an open-source job-search tool I built
for my own job hunt. I had a list of 6 things I wanted to ship: a few features, a couple of tech-debt fixes, and one risky

refactor (migrating Anthropic API calls from text-based JSON parsing to tool use).

I expected to get through 2 maybe 3 of them. Instead I shipped 13 PRs to main, all green CI, all live in production, in
a single afternoon — pair-programming with Claude.

This is what worked, what didn't, and the technical lesson that surprised me the most.

## The setup

JobSearch is a FastAPI + PostgreSQL + Redis monolith deployed on Render. Standard Python stack: 394 tests, mypy strict,

9-stage GitHub Actions CI (ruff, format, bandit, pip-audit, stylelint, CodeQL, pytest, docker build, deploy). Real production
app, used daily by exactly one person — me.

The session started simple: I asked Claude to plan the work in /ultraplan mode, and we got back a 6-PR roadmap ordered by

risk. Then we just… executed it.

## The "onion" workflow

The thing that worked best wasn't speed — it was discipline. Every PR was:

New branch from latest main
Single concern (no mixing tech debt with features)
Tests added
Push → wait for CI green → merge → delete branch
Pull main → start next PR

Sounds basic. But the discipline of "no overlapping PRs, no shortcuts, never merge without 9/9 green checks" is what kept the
velocity sustainable for 6 hours straight. We never had to roll back. Production never broke.

The reason I could keep this pace: Claude handled the typing and the verifications, I handled the decisions and the

priorities. Classic pair programming, just with one of the pair being an LLM.

## The risky one: tool use migration

The PR I was most worried about was eliminating ~250 LOC of fragile JSON parsing.

Before: every Claude API call returned text. We'd run that text through 7 parsing strategies (_clean_json_text,

_fix_unescaped_newlines, _fix_single_quotes, _strip_markdown_wrapper, _extract_and_parse_json, then a fallback that
asks Claude to fix its own broken JSON).

This worked but it was a band-aid. Every few hundred analyses we'd hit an edge case the parsers didn't cover.

After: every API call uses Anthropic's tool_use with a forced tool_choice. The schema comes from

Pydantic.model_json_schema(). The SDK gives us back a parsed dict directly. Zero local parsing.


python                                                 
  def _call_api_with_tool(
      system_prompt: str,                                                                                                      
      user_prompt: str,
      model_id: str,                                                                                                           
      max_tokens: int,                                                                                                         
      tool_name: str,
      tool_description: str,                                                                                                   
      input_schema: dict[str, Any],                         
  ) -> tuple[dict[str, Any], anthropic.types.Usage]:                                                                           
      message = client.messages.create(                                                                                        
          model=model_id,                                                                                                      
          max_tokens=max_tokens,                                                                                               
          system=[{"type": "text", "text": system_prompt,   
                   "cache_control": {"type": "ephemeral"}}],                                                                   
          messages=[{"role": "user", "content": user_prompt}],
          tools=[{"name": tool_name,                                                                                           
                  "description": tool_description,                                                                             
                  "input_schema": input_schema}],
          tool_choice={"type": "tool", "name": tool_name},                                                                     
      )                                                                                                                        
      for block in message.content:
          if getattr(block, "type", None) != "tool_use":                                                                       
              continue                                      
          tool_input = getattr(block, "input", None)                                                                           
          if isinstance(tool_input, dict):
              return cast(dict[str, Any], tool_input), message.usage                                                           
      raise RuntimeError(f"Expected tool_use block for {tool_name!r}")                                                         

  Net delta: −370 lines across anthropic_client.py + 5 obsolete test classes that no longer made sense. The "JSON parse        
  failure" bug class disappeared from the codebase entirely.                                                                   

  The surprising lesson came the next morning.                                                                                 

  The bug I didn't see coming                                                                                                  

  A day later, I was looking at production data and noticed something off. My job-quality filter wasn't flagging P.IVA (Italian
   self-employment) job ads correctly. Annunci with salary_info: "€2.500-3.000/mese P.IVA" were coming back with is_freelance: 
  false — exactly the opposite of what I wanted.                                                                               

  The prompt rule was technically still there. It just stopped working.                                                        

  After a few minutes of digging, I realized: the rule had a permissive fallback — "if the ad mentions both 'employee or       
  P.IVA', set is_freelance=false (the user can choose employee)". With the old text-parsing pipeline, this fallback rarely
  triggered because the model's output had enough noise that it usually committed to one answer.                               

  With tool use, the model follows the schema with much more literalness. The fallback now triggered too often, because the    
  model treated even a tangential mention of "P.IVA" as an ambiguous case.

  The fix was to harden the prompt rule with explicit precedence: "strong triggers in salary_info (€/day, €/hour, €/month +    
  P.IVA) override every fallback. The exception requires ALL three explicit conditions."

  The takeaway:                                                                                                                

  ▎ When you migrate from text parsing to tool use, your interpretive prompt rules need to be tightened, not loosened. The     
  ▎ model follows the schema more faithfully, but also more literally — ambiguity in the rule becomes ambiguity in the output.

  The pair-programming bit                                                                                                     

  A few observations from 6 hours of this:                                                                                     

  1. Plan first, execute second. The /ultraplan step at the start was worth more than any single PR. Without it we would have  
  drifted into rabbit holes.                                
  2. Reviews stay with the human. Claude wrote the code, but I read every diff before merging. On 2 PRs I rejected Claude's    
  first proposal because it scope-crept.                                                                                       
  3. Wakeups for CI > polling. Instead of asking "is CI green yet?" every 30 seconds, we scheduled a wakeup for the typical
  4-minute CI window. Less context churn, faster perceived workflow.                                                           
  4. Trust but verify. When Claude said "401/401 tests passing," I didn't take it at face value — I ran pytest tests/ -q myself
   before pushing. Twice it had skipped a slow test that was actually failing. Catching that took 10 seconds, not catching it  
  would have cost a CI cycle.                               
  5. No big-bang refactors. Every PR was small enough to revert in one click. The riskiest one (tool use migration, −370 LOC)  
  still went out alone, behind its own version flag.                                                                           

  What's in the repo                                                                                                           

  github.com/MK023/JobSearch — MIT, FastAPI + Anthropic Claude tool use, 401 tests, 9-stage CI, zero-downtime Alembic          
  migrations, weekly cleanup cron via GitHub Actions, persisted user preferences with JSONB whitelist.

  It's built for one user (me, hunting a DevSecOps / Cloud / Python role in Italy 🇮🇹), but the architecture and the patterns   
  are reusable. If anything in here is useful for your own AI-integrated production app, take it.

  Happy to discuss in comments — especially the tool-use migration, which I think is the right default now for any LLM call    
  where you control the schema.

  ---