add projects.staging.oryapis.dev #2288
Conversation
|
|
Hi Simon, thanks for your quick response.
We have extensive E2E tests, which would allow us to validate that there are no unforeseen problems before rolling out the change to production. While we understand your stance that, in general, you are against adding non-prod environments. We hope you understand the impact this change can have on our customer base; therefore, we require validation on staging before we can roll out this configuration to prod.
Yes, we are in control of the cookies. While we appreciate the security benefits of __Host- cookies, Ory Network cannot implement them without significant changes to our current architecture and functionality. Our system relies on configuring cookie domains and paths to support multi-domain setups and provide flexibility for various deployment scenarios. __Host- cookies strictly require the absence of a Domain attribute and a fixed Path of ‘/’, which would remove essential customization options our users depend on. Additionally, our cookie-based security model already implements strong protections such as Secure, HttpOnly, and SameSite attributes, which address many of the same security concerns as __Host- cookies. Switching to __Host- cookies would require us to redesign core components of our service and potentially break compatibility for many of our users’ existing configurations. |
|
"We have extensive E2E tests," doesn't really help me understand how it works. Do you have a bot visit sites with a browser? Why not modify that browser to use a testing list? If we make the requested PSL changes, when will your test setup pick up on those changes? |
Notes:
|
simon-friedberger
added
the
❔❔ question
|
@tricky42 Do you still need this request? We haven't received a response in over 15 days. |
Public Suffix List (PSL) Submission
Checklist of required steps
Description of Organization
Robust Reason for PSL Inclusion
DNS verification via dig
Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration, and we shall keep the
_pslTXT record in place in the respective zone(s).Submitter affirms the following:
Abuse Contact:
eMail: [email protected]
URL where abuse contact or abuse reporting form can be found:
eMail: [email protected]
For PRIVATE section requests that are submitting entries for domains that match their organization website's primary domain, please understand that this can have impacts that may not match the desired outcome and take a long time to rollback, if at all.
To ensure that requested changes are entirely intentional, make sure that you read the affectation and propagation expectations, that you understand them, and confirm this understanding.
PR Rollbacks have lower priority, and the volunteers are unable to control when or if browsers or other parties using the PSL will refresh or update.
(Link: about propagation/expectations)
Description of Organization
Ory is a modern Identity and Access Management (IAM) platform providing Identity & Login Management, OAuth2/OIDC, and Permission Management through Ory Network, our cloud service. We serve hundreds of customers globally, managing over 100 million identities. While Ory offers various deployment options including open-source and enterprise licenses, this PSL request concerns Ory Network, our instant-on global identity system where each customer project receives its own subdomain for accessing identity services.
Our platform combines enterprise-grade security with developer-friendly implementations, making it a trusted choice for organizations requiring solutions that balance user experience, privacy, and security. A key component of our security architecture is our cookie-based security model for browser applications. Instead of using token storage in localStorage or document.cookies, we implement HTTP cookies with strict security flags (secure, httpOnly, sameSite=Strict), providing best-in-class protection against common browser attack vectors such as XSS and CSRF.
Organization Website:
https://www.ory.sh
Reason for PSL Inclusion
Before adding our production domain (projects.oryapis.com) to the PSL, we need to validate in our staging environment that this change does not negatively impact our customers' authentication systems. Therefore, we first require PSL inclusion for our staging domain projects.staging.oryapis.dev.
Our cookie-based security model (detailed at https://www.ory.sh/docs/security-model) is core to our browser security architecture. Instead of using traditional token-based methods, we implement HTTP cookies with strict security flags (secure, httpOnly, sameSite=Strict) to store session states and protect against common attack vectors like XSS and CSRF. This approach requires strict cookie isolation between different project subdomains.
The staging environment mirrors our production setup, allowing us to thoroughly test the PSL integration and validate these critical security boundaries before affecting hundreds of customers' authentication systems. Each subdomain serves a different customer's authentication and identity management APIs, making proper domain isolation essential for our security architecture.
Number of users this request is being made to serve:
Hundreds of customers use our services to manage over 100 million identities.
DNS Verification