Disagreement · 52c62f95-openai-1
Primary finding
The comment asserts a stricter CSP than what is implemented, which can mislead reviewers and maintainers in a security-sensitive area.
Recommendation
Either remove 'unsafe-inline' from the CSP to match the comment, or update the comment to accurately describe the need for 'unsafe-inline' (and when/why it is included).
Counterpart finding
The block comment immediately above the CSP declares 'No unsafe-inline, no unsafe-eval — Next.js 16 + Tailwind v4 + next/font emit static styles that don't need either.' But the very next line sets style-src to 'self' 'unsafe-inline'. This is a deceptive comment that misrepresents the actual policy. A future reader (or a security reviewer relying on the comment) could be misled into believing inline styles are fully blocked when they are not. The trailing inline comment 'Tailwind utility classes are inline-equivalent in dev' further contradicts the leading comment and is itself wrong: Tailwind utility classes are class-based, not inline; what actually requires 'unsafe-inline' is Next.js's runtime-injected <style> tags or third-party inline styles, not Tailwind utilities.
Recommendation
Either (a) remove 'unsafe-inline' from style-src and fix any breakage with a nonce/hash strategy, or (b) update the block comment to accurately state that style-src retains 'unsafe-inline' and explain why. Also correct the misleading inline comment about Tailwind.
This finding didn't meet AntFleet's unanimous agreement threshold. Both frontier models review every PR independently; only findings they both flag with the same severity and category are posted to the PR. This one fell through.
read the methodology →These findings passed the unanimous gate on the same PR review. The disagreement above was filtered out; the findings below were posted.