The Security of Ephemeral Pages
이 글은 임시 웹페이지를 제공하는 서비스에서 발견된 주요 보안 취약점과 이를 해결하기 위한 구체적 방안을 다룹니다. 특히, 원본 출처에서 직접 실행되는 업로드된 HTML로 인한 저장형 XSS 위험을 HTTP 헤더와 CSP 정책 강화로 완화했습니다. 또한, 업로드 및 신고 기능에 대한 과도한 요청을 막기 위해 IP/유저 에이전트 기반의 해시를 활용한 정교한 레이트 리밋팅을 구현했습니다. 관리자 삭제 토큰에 대한 무차별 대입 공격 방지와 크로스 오리진 URL 검증도 포함되어 실무에 적용 가능한 보안 강화 사례로 유용합니다.
https://schalkneethling.com/posts/the-security-of-ephemeral-pages/
#websecurity #contentsecuritypolicy #ratelimiting #xss #netlify
🛡️ Content Security Policy in TYPO3
Content Security Policy (CSP) is a security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting of malicious content being executed in the trusted web page context.
I am playing around with the CSP - Content Security Policy of my website, actually starting from scratch, for the first time.
I have managed to set the following and the website works:
connect-src
object-src
form-action
base-uri
frame-ancestors
but as soon as I set the following, the website is no longer functional:
default-src
script-src
style-src
has anyone had similar issues and knows what I can look for to make this work? What am I doing wrong? 🤦
Two days ago, a proposal to add "unsafe-webtransport-hashes" to the Content Security Policy specification was merged.
https://github.com/w3c/webappsec-csp/issues/683
https://github.com/w3c/webappsec-csp/pull/791
Here is how I understand the proposal, based on reading it and the documentation for WebTransport. I'm by no means an expert on WebTransport - I had never heard of it before today.
WebTransport is intended to replace Web Sockets; it allows a website to connect to a server over HTTP/3.
One feature of WebTransport is serverCertificateHashes, which is passed as an argument when creating a new socket.
serverCertificateHashes allows a website to bypass the normal public key infrastructure, instead telling the browser what certificates to trust.
It does this, as the name suggests, by providing the hashes of the certificates.
There is, of course, an inherent risk which comes with replacing the existing PKI with DIY. Allowing websites to restrict usage of this feature helps mitigate some of this risk.
This proposal builds on the existing connect-src CSP policy, which controls technologies like XHR, Fetch, etc.
If a website does not set connect-src in its Content Security Policy or doesn't have a CSP, then it can use serverCertificateHashes as it wishes.
However, if it sets connect-src, then serverCertificateHashes is disallowed.
That is where unsafe-webtransport-hashes comes into play. A website can allow specific certificates to be used with serverCertificateHashes by specifying the hashes of those certificates in unsafe-webtransport-hashes, which is part of the CSP and falls under connect-src.
So, as I understand it:
All of this is based on reading the issue thread and doing a little background research. I probably got some of it, or all of it, wrong.
Point being; it is an interesting but very niche proposal.
Interesting learning today about Firefox behavior displaying video content and Content-Security-Policy.
I've got a Garage server which hosts some random content (photos, and now videos in MP4 format); there's an NGINX reverse proxy in front of it. The NGINX configuration includes a very strict CSP (which came from the CSP defaults documented for Mastodon image hosting) which includes "default-src 'none'".
There are four MP4 files in the bucket, ranging in size from 20MB to 882MB, with one at 254MB in between. All of the files except the largest one play just fine in Firefox with that CSP in place.
The largest file, however, starts playback and then a moment later Firefox says "Video cannot be played, file is corrupt.". Of course the file is not corrupt, it's fine, but whatever, writing error messages is not easy.
Using the Network console I could see that Firefox was trying to make at least one secondary request for content from this file, and was blocking itself from making the request because of the CSP! Adding "media-src: 'self'" to the CSP allows this secondary request to proceed, and the video plays fine. From the MDN docs, this CSP entry should only apply to a '<video>' element on the page, and of course there isn't one on this 'page' because this 'page' doesn't contain any HTML at all, but presumably Firefox is synthesizing an HTML page to perform the playback and that page does contain a '<video>' element.
Why this only happens on the largest of the files I cannot really guess.
My newest educational video on the #ContentSecurityPolicy is out on the @phparch #youtube channel. It's a powerful tool that can really increase the #security of your #SaaS applications.
https://www.phparch.com/2025/11/the-secret-header-that-makes-your-php-app-10x-more-secure/
New tool: resource-rewriter
https://lib.rs/crates/resource-rewriter
It takes a single HTML file with inline styles and scripts and rewrites them to be compatible with a more restrictive Content-Security-Policy (and a few other things).
I still have a few more things I'd like to add in, like automated CSP generation, a WASM playground and maybe handling style= attributes. A blog post will follow once that's in place :)
I have no patience for dealing with the #RubyOnRails core team, but if •you• do, then…
It would be super if it were possible to append values to the #ContentSecurityPolicy configuration. For example:
```ruby
Rails.application.configure do
config.content_security_policy do |policy|
policy.script_src :self, :https
if Rails.env.development?
policy.script_src << :unsafe_inline
end
end
end
```
Template initializer source: https://github.com/rails/rails/blob/main/railties/lib/rails/generators/rails/app/templates/config/initializers/content_security_policy.rb.tt
sayzard
randomTYPO3
Public Enemy Exposed
iam-py-test 
Kevin P. Fleming
Scott Keck-Warren
Kunal Mehta
Wolfgang Wagner
Jason Garber