3 ms·

Proxying from the "hot" domain (with user credentials) to a third party service is always going to be an awful idea. Why not just CNAME Mintlify to dev-docs.dis

by bri3d 10mo ago

Proxying from the "hot" domain (with user credentials) to a third party service is always going to be an awful idea. Why not just CNAME Mintlify to dev-docs.discord.com or something? This is also why an `app.` or even better `tenant.` subdomain is always a good idea; it limits the blast radius of mistakes like this.

pverheggen 10mo ago
I think the reason companies do this for doc sites is so they can substitute your real credentials into code snippets with "YOUR_API_KEY". Seems like a poor tradeoff given the security downside.
gkoberger 10mo ago
I run a product similar to Mintlify. We've made different product decisions than them. We don't support this, nor do we request access to codebases for Git sync. Both are security issues waiting to happen, no matter how much customers want them. The reason people want it, though, is for SEO: whether it's true or outdated voodoo, almost everyone believes having their documentation on a subdomain hurts the parent domain. Google says it's not true, SEO experts say it is. I wish Mintlify the best here – it's stressful to let customers down like this.
- omneity 10mo ago
  To my knowledge it's not as much hurting the parent domain as having two separate "worlds". Your docs which are likely to receive higher traffic will stop contributing any SEO juice to your main website.
- Dma54rhs 10mo ago
  What makes you say that Google claims it's not true? Google claims subdomains are completely two different domains and you'll lose all the linking/page rank stuff according to their own docs regarding SEO. Some SEO gurus claim it's not so black and white but no one knows for sure. The data does show having docs on subdomain is more harmful to your SEO if you get linked to then a lot.
  - gkoberger 10mo ago
    Here's the argument for/against it: https://www.searchenginejournal.com/ranking-factors/subdomain-subdirectory/ https://www.searchenginejournal.com/ranking-factors/subdomai... I think the answer likely is quite nuanced, for what it's worth.
odensc 10mo ago
Yep - this is the core issue that made the vulnerability so bad. And if you use a subdomain for a third-party service, make sure your main app auth cookies are scoped to host-only. Better yet, use a completely different domain like you would for user-generated content (e.g. discorddocs.com).

by bri3d 10mo ago

pverheggen 10mo ago

I think the reason companies do this for doc sites is so they can substitute your real credentials into code snippets with "YOUR_API_KEY". Seems like a poor tradeoff given the security downside.

gkoberger 10mo ago

I run a product similar to Mintlify. We've made different product decisions than them. We don't support this, nor do we request access to codebases for Git sync. Both are security issues waiting to happen, no matter how much customers want them. The reason people want it, though, is for SEO: whether it's true or outdated voodoo, almost everyone believes having their documentation on a subdomain hurts the parent domain. Google says it's not true, SEO experts say it is. I wish Mintlify the best here – it's stressful to let customers down like this.

omneity 10mo ago
To my knowledge it's not as much hurting the parent domain as having two separate "worlds". Your docs which are likely to receive higher traffic will stop contributing any SEO juice to your main website.
Dma54rhs 10mo ago
What makes you say that Google claims it's not true? Google claims subdomains are completely two different domains and you'll lose all the linking/page rank stuff according to their own docs regarding SEO. Some SEO gurus claim it's not so black and white but no one knows for sure. The data does show having docs on subdomain is more harmful to your SEO if you get linked to then a lot.
- gkoberger 10mo ago
  Here's the argument for/against it: https://www.searchenginejournal.com/ranking-factors/subdomain-subdirectory/ https://www.searchenginejournal.com/ranking-factors/subdomai... I think the answer likely is quite nuanced, for what it's worth.

odensc 10mo ago

Yep - this is the core issue that made the vulnerability so bad. And if you use a subdomain for a third-party service, make sure your main app auth cookies are scoped to host-only. Better yet, use a completely different domain like you would for user-generated content (e.g. discorddocs.com).