Claude's API now supports CORS requests, enabling client-side applications(simonwillison.net)
simonwillison.net
Claude's API now supports CORS requests, enabling client-side applications
https://simonwillison.net/2024/Aug/23/anthropic-dangerous-direct-browser-access/
172 comments
I offer both in https://kidzfun.art. If you're non-technical, you can buy packs of 100 images and it uses my key to access Dall-E, or you can provide your own key and pay nothing to me. The vast majority of users go the simpler way, but it's a nice bonus for technical users to just reuse their own key. The difference with your approach is that I store an encrypted copy server side as I do all the AI generation on the server.
I don’t understand why you’re being downvoted. I think this is a reasonable approach. If you want convenience, you pay for it – otherwise it‘s BYOK.
I think it was probably the gratuitous inclusion of the url
It wasn’t gratuitous at all and the “self-promotion police” are an insufferable plague on this website.
Not saying it isn't reasonable, but I'm guessing people might downvote because of storing secrets server-side rather than passing them on from the frontend and saving them there instead. People get worried as soon as secrets are stored anywhere :)
I think the biggest issue is that the vast majority of all Internet Users, including 'techies' really dont understand Secretes, Security, risks, non-risks etc...
I think that What HN (the site) is actually lacking is any kind of formal education [section] on the state of tech. Esp. given how much of SV tech zeitgeist flows through the frontpage of HN and the folks in its orbit - HN is missing out on a service that could look like a "tech News podcast" where Khan Acadamy meets OpenCourseware CS level snippets...
As an example - there have been a flurry of tools and launches and shows to HN recently that if there was a 15 minute video explaining the TechLego - and you could watch all these announcements and little educational doo-dads for the various tech componentry and tooling being shown here - a scrappy motivated modern version of 20-year-old [Every Grey HNer] could build wonders with...
We need to give people a solid grasp of all these concepts and issues, best practice, and the WHY we think the way we think about things such as secrets, auth, security. (the boring layer in OSI for most)
I think that What HN (the site) is actually lacking is any kind of formal education [section] on the state of tech. Esp. given how much of SV tech zeitgeist flows through the frontpage of HN and the folks in its orbit - HN is missing out on a service that could look like a "tech News podcast" where Khan Acadamy meets OpenCourseware CS level snippets...
As an example - there have been a flurry of tools and launches and shows to HN recently that if there was a 15 minute video explaining the TechLego - and you could watch all these announcements and little educational doo-dads for the various tech componentry and tooling being shown here - a scrappy motivated modern version of 20-year-old [Every Grey HNer] could build wonders with...
We need to give people a solid grasp of all these concepts and issues, best practice, and the WHY we think the way we think about things such as secrets, auth, security. (the boring layer in OSI for most)
Yesyesyesyesyes I didn't realize how badly this is needed and how much I would like to work on this until you brought it up.
It's wild how much useful information flows through the HN Zeitgeist! I singlehandedly attribute my career success/position to keeping up with it all
It's wild how much useful information flows through the HN Zeitgeist! I singlehandedly attribute my career success/position to keeping up with it all
[deleted]
The UX could be so much better and more secure. This type of use case is a perfect fit for OAuth2.
Current UX:
1. User hits your app
2. You tell them to go to Anthropic and generate an API key. You'll probably need to give them instructions on how to do so, which will become outdated over time as Anthropic makes changes to their website.
3. User goes to Anthropic and generates an API key
4. User manually navigates back to your app and pastes the key
OAuth2 UX:
1. You redirect the user to Anthropic
2. The user approves your app getting access
3. Anthropic redirects the user back to you and your app starts working.
For the life of me I don't understand why orgs don't implement OAuth2 for basically everything. Yes it is more complicated on the developer side, but that's for good security reasons. And it isn't that bad, and well worth the moderate time investment.
Current UX:
1. User hits your app
2. You tell them to go to Anthropic and generate an API key. You'll probably need to give them instructions on how to do so, which will become outdated over time as Anthropic makes changes to their website.
3. User goes to Anthropic and generates an API key
4. User manually navigates back to your app and pastes the key
OAuth2 UX:
1. You redirect the user to Anthropic
2. The user approves your app getting access
3. Anthropic redirects the user back to you and your app starts working.
For the life of me I don't understand why orgs don't implement OAuth2 for basically everything. Yes it is more complicated on the developer side, but that's for good security reasons. And it isn't that bad, and well worth the moderate time investment.
You have to remember that dev time is always at a premium. Even if it takes one week to build OAuth2 support, that's one week delay on other features. It's always a matter of priorities.
Sure but the alternative we are talking about here is encouraging developers to paste their API keys into random web pages.
I don’t think we should accept the argument that since implementing a respectable authorization scheme might take a bit of effort, it’s okay for sites to ask users to just hand over their password.
I don’t think we should accept the argument that since implementing a respectable authorization scheme might take a bit of effort, it’s okay for sites to ask users to just hand over their password.
Wait... can't they use Claude to build this for them? :)
Interesting; I've build a similar application for assisting with the translation of localization files (mozilla's project fluent) and for the same reason as well.
I build this stuff for fun; and because I needed something like it. I don't expect to be making money of it so I want to minimize operational overhead and hassle. So it suits me to not have to build and run an application server for this; even though I'm well capable of building such a thing.
It's available here: fluent-ai.jillesvangurp.com if people want to play with this. It uses openai in the browser and probably can work pretty easily with claude as well. Bring your own key. It's all open source if people want to play with this.
I build this stuff for fun; and because I needed something like it. I don't expect to be making money of it so I want to minimize operational overhead and hassle. So it suits me to not have to build and run an application server for this; even though I'm well capable of building such a thing.
It's available here: fluent-ai.jillesvangurp.com if people want to play with this. It uses openai in the browser and probably can work pretty easily with claude as well. Bring your own key. It's all open source if people want to play with this.
I do the same, I make chrome extensions and my most recent extension uses a byo api key model for calls to an LLM.
Means I can offer the service for free and not worry about hosting keys, serving ads, and storing users keys in a db. Everything can be done client side.
Good to hear I’m not alone in the endeavour, what software are you building?
Means I can offer the service for free and not worry about hosting keys, serving ads, and storing users keys in a db. Everything can be done client side.
Good to hear I’m not alone in the endeavour, what software are you building?
I made two one-page react apps
https://www.livetranslate.net/
https://www.subsgpt.com/
Second one is more refined but both are functional.
I was pleasantly surprised somebody made a YouTube tutorial in Japanese about the latter https://www.youtube.com/watch?v=8gAkvZYayEc - feels like retro internet where people share things on their personal webpages.
Curiously the first one also landed me a contracting opportunity for a company that wanted to add live captions to their product and we went live with my help.
I also made a decentralized twitter dapp ages ago but AI apps definitely have had more interest.
https://www.livetranslate.net/
https://www.subsgpt.com/
Second one is more refined but both are functional.
I was pleasantly surprised somebody made a YouTube tutorial in Japanese about the latter https://www.youtube.com/watch?v=8gAkvZYayEc - feels like retro internet where people share things on their personal webpages.
Curiously the first one also landed me a contracting opportunity for a company that wanted to add live captions to their product and we went live with my help.
I also made a decentralized twitter dapp ages ago but AI apps definitely have had more interest.
Do you think it would be possible to attach other language SRTs in the context? For example when translating English to Polish, the LLM has no idea whether the lines are spoken by a man or a woman, so the polish translation will be very confusing. However, if I could give the model both English and French subtitles, the gendered words from French would let the model avoid the confusion and the polish translation could be much more accurate. Does that make sense?
While this is nice, I don't think the dangers are discussed enough. A user has no guarantee their key isn't just being sent to some malicious third party. Normalizing this seems dangerous because it only takes a couple bad actors.
Sure you could try to get people to issue / delete keys every time they use an online app but it seems unlikely most users will do that.
Sure you could try to get people to issue / delete keys every time they use an online app but it seems unlikely most users will do that.
The browser doesn't need to facilitate this.
They could generate an application specific key. Could do that every time one uses the application by forwarding though the website issuing the key and back.
I want government id to work like that. You authorize the website on the .gov then the website only gets a key, no further information. The only thing to knows about the key is that each citizen gets to generate one key for each [registered] domain.
They could generate an application specific key. Could do that every time one uses the application by forwarding though the website issuing the key and back.
I want government id to work like that. You authorize the website on the .gov then the website only gets a key, no further information. The only thing to knows about the key is that each citizen gets to generate one key for each [registered] domain.
probably not a good idea for your government to know their each citizen what kind of websites uses. However there are similar idea currently in some crypto projects that trying to solve it to make it distributed, so that if you e.g. like gambling the government won't know about it but website that provide gambling services can still check that you are from non banned countries and adult without any more detailed KYC
I love this pattern as well, but as some comments have pointed out, there is a pitfall of security risk (you don't know where your API key is going). I think it would be really cool if more services let you cap API key usage, so it's almost like a virtual credit card number. I could then put in API keys to sites without worrying and knowing that at most, I can lose, say, $10 or something.
This is absolutely the thing I most want: it should be trivially easy to create a dedicated API key with e.g. a $5 maximum spend that I can share with a "bring your own key" tool.
Being able to issue those via an OAuth flow as opposed to copy-and-paste would be nice, but the fundamental thing I want is per-app spending limits.
Being able to issue those via an OAuth flow as opposed to copy-and-paste would be nice, but the fundamental thing I want is per-app spending limits.
Obviously you aware, but let me still say it: openrouter is for me a trivially easy way to create dedicated keys with max limit https://openrouter.ai/credits or am I missing something?
oh this is interesting thanks for linking gonna check em out
This is pretty much exactly what an oauth2 flow is. You generate a single-use-specific token and constrain it with the limited permissions you choose. If a site wants to offer an oauth token flow where users can put a time or credit usage limit on the token they absolutely can do so.
Could ads even support such AI heavy use cases?
I'm kind of out of touch with current AI API pricing and ad revenues, so i'm curious how the economics work out.
I'm kind of out of touch with current AI API pricing and ad revenues, so i'm curious how the economics work out.
Yes, we're now at an inflection point where this is starting to become possible. gpt-4o mini costs $0.15 per 1 million input tokens, and $0.60 per 1 million output. This is cheap enough that it can, at least in some cases, be funded by ad impressions.
Of course, the implications here are mixed. If you want to build an ad-supported tool that actually helps people, that's great. But it also means it now makes clear financial sense to fill the web with AI-generated garbage with the assumption that that ad impressions will pay for it.
Of course, the implications here are mixed. If you want to build an ad-supported tool that actually helps people, that's great. But it also means it now makes clear financial sense to fill the web with AI-generated garbage with the assumption that that ad impressions will pay for it.
Another implication is that you're dependent on it remaining cheap enough. You risk VC money running out and them having to jack up prices, or them doing so because they managed to capture the whole market.
I don’t think it’s cheap because VC money is subsidizing losses on every token. It’s getting cheaper because models and infrastructure are becoming more efficient.
And I really don’t think any of the AI API providers can “capture the whole market”. There are at least 3 of ballpark equal capability, so I don’t see how dramatically raising prices is compatible with dominant market share.
And I really don’t think any of the AI API providers can “capture the whole market”. There are at least 3 of ballpark equal capability, so I don’t see how dramatically raising prices is compatible with dominant market share.
Even if the inference is getting cheaper, all the frontier companies are running massive losses building and serving it. That has to come back eventually, that's just how capitalism works.
Just remember that Netflix didn't start really jacking up the price till after the other players entered the streaming war, when they were pioneers it was dirt cheap. The existence of Disney+ didn't stop them at all.
Just remember that Netflix didn't start really jacking up the price till after the other players entered the streaming war, when they were pioneers it was dirt cheap. The existence of Disney+ didn't stop them at all.
One major difference is that Netflix has a monopoly on much of its content, but LLMs are fungible.
Dell was never able to jack up its prices, even when it was dominant in the market, because people would just go to another vendor. I think OpenAI is closer to a Dell than a Netflix.
Dell was never able to jack up its prices, even when it was dominant in the market, because people would just go to another vendor. I think OpenAI is closer to a Dell than a Netflix.
if new models won't require to have significantly better hardware then I think eventually many cases will be run on locally. Currently you have macbook pro with even 128GB RAM - of course almost nobody has it but those hardware will be mainstream common in ~5 years. You already can have ollama - you just need to have equivalent preinstalled by Microsoft/Apple/Google on their all new devices - again most likely this will happen in <5 years.
Haha, maybe Gen AI needs will finally drive up memory needs and the memory installed in most device, but i doubt it.
Apple still happily takes 1800$ for 8GB laptops. Wouldn't be surprised if that were their most sold SKU ans the laptops sold today will be around for quite some time.
Apple still happily takes 1800$ for 8GB laptops. Wouldn't be surprised if that were their most sold SKU ans the laptops sold today will be around for quite some time.
Fixed costs vs variable costs. That’s how capitalism works.
This is also pricing for customers, not what it actually costs to run.
Yes, but that's what's relevant, right? If I create a service, I don't really care if OpenAI makes a killing or is subsidizing my cost with venture capital, what matters to me is how much I pay to OpenAI, and how much revenue my service generates.
It's relevant as far as the providers of said LLM inference could always swoop in, undercut you and take your business if they feel like it. But they could do that anyways, no matter if they do it at a profit or not.
This assumes the service developer adds no value to this process. Because otherwise its like saying nVidia can swoop in on EA's business.
Edit: s/App/service.
Edit: s/App/service.
[deleted]
Another benefit of BYOK is it simplifies the implementation. You don't need to spend as much time protecting against the attack vector where they rack up a big bill against your key.
I do the same now for a firefox extension I wrote (automatic form-filler that works way way better than anything else out there).
So it's also "bring your own keys" but then how do you monetize at all?
I personally don't like "bring your own keys" at all from a user-friendlyness perspective. It means that you exclude the vast majority of potential users, because they don't know what that even means. Even "create an account" is more user friendly.
So it's also "bring your own keys" but then how do you monetize at all?
I personally don't like "bring your own keys" at all from a user-friendlyness perspective. It means that you exclude the vast majority of potential users, because they don't know what that even means. Even "create an account" is more user friendly.
"Bring your own keys" can mean a "log in with OpenAI" button. Having users navigate through a third party's arcane dev portal isn't a good experience, but that third party can make it painless for users if they so choose.
They don't; OpenAI maintains a separation between "general population" ChatGPT Frontend and the LLM API on purpose. It's arguably a good purpose.
And the issue should really be inverted: it's not about excluding less technically savvy users - it's about recognizing a market niche of more sophisticated users, that really want that feature, can likely pay more for it, give you word-of-mouth marketing for free if you execute well. It's a niche so underserved that you don't even have to compete with scammers and shovelware all that much.
And the issue should really be inverted: it's not about excluding less technically savvy users - it's about recognizing a market niche of more sophisticated users, that really want that feature, can likely pay more for it, give you word-of-mouth marketing for free if you execute well. It's a niche so underserved that you don't even have to compete with scammers and shovelware all that much.
I absolutely think that OpenAI or Anthropic should provide such integration. It’s very similar to how Apple Pay centralises your subscriptions and makes payments secure and simple. Would be nice if AI labs had an equivalent portal where each authorized app gets its own key and I can cancel any time and control my spending. Finally that might enable some kind of monetisation if OpenAI or Anthropic give developers a cut, e.g. 10% mark-up that goes to the authorized app.
> Finally that might enable some kind of monetisation if OpenAI or Anthropic give developers a cut, e.g. 10% mark-up that goes to the authorized app.
I was totally against you until this, but it’s an interesting idea. Its still early, but seems like OpenAI hasn’t succeeded any more to be broad consumer product past the core Chat experience. Building an AI OAuth platform would be an interesting way to be sticky and avoid being a commodity. But it’d give developers more leverage vs their custom-GPT product, and it’d shift charging per-use for an API to “unlimited” per month for a single subscription fee.
Generally, a product shouldn’t tie themselves to an API provider (eg OpenAI) when it could’ve been an implementation detail. If you hide the actual API from users, you can swap it for cheaper or better ones as the market evolves. If you give up the account access to a providers OAuth, and you give up control over that implementation, you risk being really stuck to a market loser and no direct relationship with users.
Getting paid for it though…. That would be an interesting twist. But I’m not sure it’d make sense as anything but a bulk discount. The problem is that it doesn’t make sense to pay a developer to use your paid product, unless you get a relationship with the end users like Google Search defaults in browsers. But again, it doesn’t make sense to give OpenAI that relationship if you don’t have to.
I was totally against you until this, but it’s an interesting idea. Its still early, but seems like OpenAI hasn’t succeeded any more to be broad consumer product past the core Chat experience. Building an AI OAuth platform would be an interesting way to be sticky and avoid being a commodity. But it’d give developers more leverage vs their custom-GPT product, and it’d shift charging per-use for an API to “unlimited” per month for a single subscription fee.
Generally, a product shouldn’t tie themselves to an API provider (eg OpenAI) when it could’ve been an implementation detail. If you hide the actual API from users, you can swap it for cheaper or better ones as the market evolves. If you give up the account access to a providers OAuth, and you give up control over that implementation, you risk being really stuck to a market loser and no direct relationship with users.
Getting paid for it though…. That would be an interesting twist. But I’m not sure it’d make sense as anything but a bulk discount. The problem is that it doesn’t make sense to pay a developer to use your paid product, unless you get a relationship with the end users like Google Search defaults in browsers. But again, it doesn’t make sense to give OpenAI that relationship if you don’t have to.
> So it's also "bring your own keys" but then how do you monetize at all?
Why do you need to monetize? The original comment you replied to talked about making something for the world and sharing it. They said they didn’t want to maintain it, they didn’t want to be obligated to care for it. You can’t make that choice if people are paying you (or at least shouldn’t…).
I don’t understand the BYOx use case for a monetized product. If you’re BYO api, you’re essentially missing the opportunity to monetize a spread on API requests. The more a customer uses your product (because it’s good), the more you’d make. That’s the best case scenario because it means everyone is finding value.
Why do you need to monetize? The original comment you replied to talked about making something for the world and sharing it. They said they didn’t want to maintain it, they didn’t want to be obligated to care for it. You can’t make that choice if people are paying you (or at least shouldn’t…).
I don’t understand the BYOx use case for a monetized product. If you’re BYO api, you’re essentially missing the opportunity to monetize a spread on API requests. The more a customer uses your product (because it’s good), the more you’d make. That’s the best case scenario because it means everyone is finding value.
> Why do you need to monetise?
Some people, myself included, are trying to earn a living creating software that helps people in some way. Just like any other physical or digital service, it’s fair to charge for a useful tool
> I don’t understand BYOx use case for monetised product
In my case, BYO keys turns out way cheaper for the end user. For instance my tool calls an LLM API. If I were to host the keys myself, I’d be charged $X for Y calls.
By getting the user to bring their own key, in my case the user easily fits into the free tier of the LLM (Gemini in my case) so the product costs me $0 to run, and I just charge a small service fee for me having created the product.
This allows me to keep building useful tools, some free (7 of 8 projects so far) and some paid (1 of 8)
Some people, myself included, are trying to earn a living creating software that helps people in some way. Just like any other physical or digital service, it’s fair to charge for a useful tool
> I don’t understand BYOx use case for monetised product
In my case, BYO keys turns out way cheaper for the end user. For instance my tool calls an LLM API. If I were to host the keys myself, I’d be charged $X for Y calls.
By getting the user to bring their own key, in my case the user easily fits into the free tier of the LLM (Gemini in my case) so the product costs me $0 to run, and I just charge a small service fee for me having created the product.
This allows me to keep building useful tools, some free (7 of 8 projects so far) and some paid (1 of 8)
BYOK frees application developers from being inference resellers and enables generous free tiers where you convert users because they love your app and want advanced functionality, not because it has a 7 day free trial then they can't use it anymore.
Also, subscriptions are a garbage business model from the user perspective, it's literally a dark pattern. They make sense for things with recurring costs to provide, but for instance, I should be able to buy a copy of Cursor and plug my key in and use it forever, and only shell out if I want upgrades. It's a subscription service because they're trying to bleed their users dry, and I'm sick of it.
Also, subscriptions are a garbage business model from the user perspective, it's literally a dark pattern. They make sense for things with recurring costs to provide, but for instance, I should be able to buy a copy of Cursor and plug my key in and use it forever, and only shell out if I want upgrades. It's a subscription service because they're trying to bleed their users dry, and I'm sick of it.
> So it's also "bring your own keys" but then how do you monetize at all?
TypingMind.com is a "bring you own API key" (obviously, being a LLM frontend), that's also successfully monetizing users. The secret is that it's actually a very good product; until recently, it was far ahead of the official tools (I mean, they had plugins for like half a year before OpenAI started talking about "GPTs"), so paying for the license feels worth it (definitely was, when TypingMind was strictly better than ChatGPT Plus subscription).
It's also not a subscription - another reason "bring your own keys" apps are interesting, because you likely already have a paid subscription with the API vendor; adding another one on top of that needs some good justification.
Anyway, "bring your own key" users are a different market from general audience, and unlike the latter, it isn't already saturated with fly-by-night garbage and scam extensions, so you can both charge more for that feature, and have smaller costs marketing it.
TypingMind.com is a "bring you own API key" (obviously, being a LLM frontend), that's also successfully monetizing users. The secret is that it's actually a very good product; until recently, it was far ahead of the official tools (I mean, they had plugins for like half a year before OpenAI started talking about "GPTs"), so paying for the license feels worth it (definitely was, when TypingMind was strictly better than ChatGPT Plus subscription).
It's also not a subscription - another reason "bring your own keys" apps are interesting, because you likely already have a paid subscription with the API vendor; adding another one on top of that needs some good justification.
Anyway, "bring your own key" users are a different market from general audience, and unlike the latter, it isn't already saturated with fly-by-night garbage and scam extensions, so you can both charge more for that feature, and have smaller costs marketing it.
I think with some good UX that people suggested in different post (such as OAuth etc) it could work even with non tech savy users. Similar deals happens very often e.g. when you are renting or leasing a car you still have to pay yourself for gas. Same with renting long term for accomodation you pay utilities yourself.
Bring your own keys to minimise costs, you can still charge a subscription or one off charge for the base service if it’s a SaaS extension or similar
What's the name of the extension. I was looking for something like this recently
Outdated proof of concept version (can only use super slow local LLM using Ollama with llama3.1): https://addons.mozilla.org/en-US/firefox/addon/llm-form-fill...
Will probably update it in the coming weeks with one that can use LLMs through openrouter (Claude and others). I'm testing that now and fills forms in < 5 sec, usually better than existing tools (roboform, Bitwarden, ect).
Will probably update it in the coming weeks with one that can use LLMs through openrouter (Claude and others). I'm testing that now and fills forms in < 5 sec, usually better than existing tools (roboform, Bitwarden, ect).
I put together https://nfriedly.github.io/contributor-locations/ a while back, which has the same idea except that the access token is optional. GitHub's API provides a small number of request without one, but adding an API key will enable it to do more.
I’ve always thought this would be a cool thing to offer, one thing that I’ve asked myself though is why should I trust you to use my key? Who guarantees that you’re not going to abuse it or use it in an inefficient way?
I’m unfamiliar with how these keys are priced but I guess they still use number of tokens that you input? What happens if one day your software has a bug that sends 1k tokens multiple times and I get charged for it because I’ve used my key?
Note that this is not a complaint and I would definitely love a “bring my key to use for free” tier, just a legitimate question that I asked myself from time to time.
On the other hand, I trust you very much in doing your best work to avoid any bug like the one I’ve presented above and squeeze every little penny out of your key to maximise earnings.
Finally, how do you make people entrust you with their keys?
I’m unfamiliar with how these keys are priced but I guess they still use number of tokens that you input? What happens if one day your software has a bug that sends 1k tokens multiple times and I get charged for it because I’ve used my key?
Note that this is not a complaint and I would definitely love a “bring my key to use for free” tier, just a legitimate question that I asked myself from time to time.
On the other hand, I trust you very much in doing your best work to avoid any bug like the one I’ve presented above and squeeze every little penny out of your key to maximise earnings.
Finally, how do you make people entrust you with their keys?
The browser runs the code, which is open-sourced. You can look at the network tab of the debugging console or isolate the browser completely by sand boxing it. I agree that UX can be improved but that’s more on the browser side.
OpenRouter.ai does this pretty well. It has a pretty reasonable flow. It supports enough free models that you can do at least _something_ without a person having to pay anything (even if quality is a bit iffy). They have user-set spending limits, and each key is bound to the service. Their privacy policies seem decent.
The other option is Gemini, which has enough free credits to really be free for any small app. Unfortunately you can't use that through OpenRouter, you need your own developer account to be able to take advantage of Gemini's free offering.
The other option is Gemini, which has enough free credits to really be free for any small app. Unfortunately you can't use that through OpenRouter, you need your own developer account to be able to take advantage of Gemini's free offering.
> A live transcription and translation app that uses microphone input. This is useful for watching proprietary content and facilitating communication.
It would be funny to transcribe someones speech, improve the grammar and play it back in their own voice.
It would be funny to transcribe someones speech, improve the grammar and play it back in their own voice.
Yes I couldn’t agree more. I wish there was more support for this; like for example a system where users can be sure that the key cannot be stolen by the app.
Yeah, I also love this style of web app, for the same reasons you note!
I made https://github.com/pickledish/cardi as a kind of dynamoDB-based bookmark keeping tool in this style :) though I haven't worked on it in a couple of years.
I made https://github.com/pickledish/cardi as a kind of dynamoDB-based bookmark keeping tool in this style :) though I haven't worked on it in a couple of years.
Web security noob here. Why does CORS even exist? The fact that a website can’t make a request to another website unless that domain likes it is kind of insane to me. Everyone in the comments here is going on about how maybe the user’s API key gets leaked by a malicious application or whatever but, like, when I write software that isn’t in the browser I can just send a request to anyone without restrictions and as far as I can tell the world has not ended. Why is the browser any different?
>The fact that a website can’t make a request to another website unless that domain like it
That's wrong. Any website can make a request to any other website. The same origin policy will prevent READING the response, not making the request. This is to prevent evil.com from making a request to email.com and reading all your emails.
CORS was invented as a way to partially disable the same origin policy for websites that want to allow their responses to be read by other sites. Note that CORS is a way to disable blocking. Most people think CORS blocks things, but that's a misconception. The same origin policy blocks things, and CORS can partially disable it. CORS = Cross Origin Resource Sharing. The Sharing refers to how it disables blocking.
(This is a slight simplification, because I'm ignoring complex CORS.)
That's wrong. Any website can make a request to any other website. The same origin policy will prevent READING the response, not making the request. This is to prevent evil.com from making a request to email.com and reading all your emails.
CORS was invented as a way to partially disable the same origin policy for websites that want to allow their responses to be read by other sites. Note that CORS is a way to disable blocking. Most people think CORS blocks things, but that's a misconception. The same origin policy blocks things, and CORS can partially disable it. CORS = Cross Origin Resource Sharing. The Sharing refers to how it disables blocking.
(This is a slight simplification, because I'm ignoring complex CORS.)
CORS - or specifically, not permitting cross-origin requests by default - is for preventing CSRF, cross-site request forgery. In particular if the user's credentials (cookies) are passed along with a request to a third party site, then the first party site can act as the user with the user's authority. In other words, evil.com could e.g. send emails on your behalf by making direct requests to your email provider's web interface.
That's not really correct.
CORS and the same origin policy don't protect against CSRF attacks by default, at least if we're using the standard definition of CSRF attacks.
An attacker can still "send emails on your behalf by making direct requests to your email provider's" HTTP API even with CORS and the same origin policy in their default settings, as long as your email provider doesn't implement CSRF protection (e.g. anti-CSRF token or Origin header checks). That's why all state-changing HTTP handlers need to implement CSRF protection.
CORS and the same origin policy don't protect against CSRF attacks by default, at least if we're using the standard definition of CSRF attacks.
An attacker can still "send emails on your behalf by making direct requests to your email provider's" HTTP API even with CORS and the same origin policy in their default settings, as long as your email provider doesn't implement CSRF protection (e.g. anti-CSRF token or Origin header checks). That's why all state-changing HTTP handlers need to implement CSRF protection.
Ok but like why would you pass cookies along
Because in the 90s/early 2000s someone thought it was a good idea to send cookies for the given site along with all requests (probably a good move, since it would stink to have to tell the browser somehow to explicitly send a cookie for every request, even ones initiated outside of JS).
You could say that sites instead must prescribe a "send-cookies-when-requests-are-from-this-site" header, but that's kind of the same thing as CORS.
You could say that sites instead must prescribe a "send-cookies-when-requests-are-from-this-site" header, but that's kind of the same thing as CORS.
We used to rewrite the session ID into all link href and form action URLs for browsers that didn't enable/support cookies. If any link or form did not contain the SID, the app broke.
It was tedious.
It was tedious.
Just to add to the sibling comment - you don’t get a choice to pass cookies or not, the browser just includes them automatically.
Lots of replies here talking about cookies and CSRF, but a bigger concern in my opinion is intranets.
If you work somewhere with a network access based intranet you might have eg a private wiki at https://wiki.internal-corp/
Without CORS, anyone from your company visiting a malicious external website could have data stolen from that “private” intranet site using fetch()
If you work somewhere with a network access based intranet you might have eg a private wiki at https://wiki.internal-corp/
Without CORS, anyone from your company visiting a malicious external website could have data stolen from that “private” intranet site using fetch()
CORS is basically a backwards compatible hack to "fix" the bug that cookies are sent on third party requests by default.
The canonical issue that CORS solves is:
1. I log into my bank. 2. I load an untrusted site. 3. That site does `POST https://mybank.example/transfer` to transfer my money to them.
This works because of the braindead decision to include the cookies obtained in step 1 in the request made in step 3.
But to avoid breaking the web they had to do this "gently". So they did the following:
1. Add the Origin: header so that sites could check for this problem. (opt-in protection) 2. Add CORS for as much as they could without breaking too many existing sites (opt-out protection).
If you are designing a site what you probably want to do is check the Origin header and just set `Access-Control-Allow-Origin: *` (which is better than mirroring the origin as it blocks automatically-added credentials like cookies).
This doesn't fully solve the problem due to the legacy compatibility carve-out in 2 (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...). But was unfortunately necessary to help hotfix existing sites that were vulnerable while avoiding breaking too much (in which case it would never ship). Notably this carve-out includes HTML <form> POSTs! So if you use regular HTML forms on your site you still need to opt-in to proper protection.
These days most browser partition cookies by top-level origin anyways, so CORS is mostly obsolete. But you can't rely on that.
People will often tell you that CORS is about controlling which origins can see your content. That is mostly false. Because you can easily run a CORS proxy to access any publicly available content. What CORS does is simply prevent implicitly added authentication such as cookies and basic auth from being sent cross-domain by default (except for the carve out)
The canonical issue that CORS solves is:
1. I log into my bank. 2. I load an untrusted site. 3. That site does `POST https://mybank.example/transfer` to transfer my money to them.
This works because of the braindead decision to include the cookies obtained in step 1 in the request made in step 3.
But to avoid breaking the web they had to do this "gently". So they did the following:
1. Add the Origin: header so that sites could check for this problem. (opt-in protection) 2. Add CORS for as much as they could without breaking too many existing sites (opt-out protection).
If you are designing a site what you probably want to do is check the Origin header and just set `Access-Control-Allow-Origin: *` (which is better than mirroring the origin as it blocks automatically-added credentials like cookies).
This doesn't fully solve the problem due to the legacy compatibility carve-out in 2 (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...). But was unfortunately necessary to help hotfix existing sites that were vulnerable while avoiding breaking too much (in which case it would never ship). Notably this carve-out includes HTML <form> POSTs! So if you use regular HTML forms on your site you still need to opt-in to proper protection.
These days most browser partition cookies by top-level origin anyways, so CORS is mostly obsolete. But you can't rely on that.
People will often tell you that CORS is about controlling which origins can see your content. That is mostly false. Because you can easily run a CORS proxy to access any publicly available content. What CORS does is simply prevent implicitly added authentication such as cookies and basic auth from being sent cross-domain by default (except for the carve out)
I agree with how you describe the behavior, but the terminology you use differs from how I understand things.
The canonical example you give for something CORS and the same origin policy protect against isn't even protected against by default (as you mention), because it requires additional opt-in protection from mybank.example . Why not use a canonical example that is protected against by default? Like evil.com reading all my emails by making a request to email.com ?
You describe CORS as blocking things. I think it's the same origin policy that blocks things, and CORS (Cross Origin Resource Sharing) unblocks things ("sharing"=unblocking).
The canonical example you give for something CORS and the same origin policy protect against isn't even protected against by default (as you mention), because it requires additional opt-in protection from mybank.example . Why not use a canonical example that is protected against by default? Like evil.com reading all my emails by making a request to email.com ?
You describe CORS as blocking things. I think it's the same origin policy that blocks things, and CORS (Cross Origin Resource Sharing) unblocks things ("sharing"=unblocking).
It is protected by if the request uses JSON or similar. The point is still that this is the target problem that it is trying to address.
> Why not use a canonical example that is protected against by default?
I think demonstrating how full of holes the default policy is is a great way to emphasis that you should not rely on the default protections. It is a huge hack and you should put into place proper protections if your site uses any form of implicit credentials.
> You describe CORS as blocking things. I think it's the same origin policy that blocks things
CORS and the same origin policy are the same thing, two sides of the same coin. They express what is allow and what isn't. CORS is a configuration layer for the same origin policy, allowing you to change the default policy.
> Why not use a canonical example that is protected against by default?
I think demonstrating how full of holes the default policy is is a great way to emphasis that you should not rely on the default protections. It is a huge hack and you should put into place proper protections if your site uses any form of implicit credentials.
> You describe CORS as blocking things. I think it's the same origin policy that blocks things
CORS and the same origin policy are the same thing, two sides of the same coin. They express what is allow and what isn't. CORS is a configuration layer for the same origin policy, allowing you to change the default policy.
>It is protected by if the request uses JSON or similar.
Only if the server checks that the Content-Type header is JSON. If the server ignores the Content-Type header and simply decodes it as JSON, it's not protected. I think there are probably a lot of servers that simply decode the body as JSON without first checking the Content-Type header and thus the same origin policy doesn't protect them from CSRF.
>The point is still that this is the target problem that it is trying to address.
It doesn't seem that way to me. The same origin policy successfully prevents one website from reading the content of another website. It's fully addressed. It seems to me that's the primary problem it's trying to address. The problem of one website sending requests to another website is only partially addressed, so it seems to me that's considered a secondary problem.
>I think demonstrating how full of holes the default policy is is a great way to emphasis that you should not rely on the default protections.
The default policy is full of holes for sending requests, but not for reading the response. I agree you shouldn't rely on the default protections for sending requests, and should implement your own CSRF protection for all state-changing handlers. But I think it's fine to rely on the default protection for reading responses, and thus I don't think it's necessary to recommend CSRF protection for non-state-changing handlers.
The reason I always first describe the same origin policy and CORS in terms of reading responses is that I think it leads to less confusion. If I first explain about sending requests, I have to explain that it doesn't really work, and people thus are confused about what the purpose of the same origin policy and CORS is if it doesn't even protect against the thing it was designed to protect against. Either that or they mistakenly think it does protect against sending requests, and implement sites with CSRF vulnerabilities erroneously thinking the same origin policy and CORS will protect them. By explaining first about reading responses, people quickly understand that. I then explain that it doesn't protect against sending requests, and thus state-changing handlers need CSRF protection to be implemented.
>CORS and the same origin policy are the same thing, two sides of the same coin. They express what is allow and what isn't. CORS is a configuration layer for the same origin policy, allowing you to change the default policy.
I guess I can see that, but the names of them don't really lend themselves to that understanding. The same origin policy is about same origins. If it starts allowing cross-origin communication, then it's no longer living up to its name. So I see that as it being disabled. Similarly CORS is about cross-origin sharing. If it starts blocking things, then it's not doing sharing, and thus not living up to its name.
According to Wikipedia the history backs up my understanding. It says the same origin policy was created in 1995, and CORS came later, first proposed in 2004.
https://en.wikipedia.org/wiki/Same-origin_policy
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
Only if the server checks that the Content-Type header is JSON. If the server ignores the Content-Type header and simply decodes it as JSON, it's not protected. I think there are probably a lot of servers that simply decode the body as JSON without first checking the Content-Type header and thus the same origin policy doesn't protect them from CSRF.
>The point is still that this is the target problem that it is trying to address.
It doesn't seem that way to me. The same origin policy successfully prevents one website from reading the content of another website. It's fully addressed. It seems to me that's the primary problem it's trying to address. The problem of one website sending requests to another website is only partially addressed, so it seems to me that's considered a secondary problem.
>I think demonstrating how full of holes the default policy is is a great way to emphasis that you should not rely on the default protections.
The default policy is full of holes for sending requests, but not for reading the response. I agree you shouldn't rely on the default protections for sending requests, and should implement your own CSRF protection for all state-changing handlers. But I think it's fine to rely on the default protection for reading responses, and thus I don't think it's necessary to recommend CSRF protection for non-state-changing handlers.
The reason I always first describe the same origin policy and CORS in terms of reading responses is that I think it leads to less confusion. If I first explain about sending requests, I have to explain that it doesn't really work, and people thus are confused about what the purpose of the same origin policy and CORS is if it doesn't even protect against the thing it was designed to protect against. Either that or they mistakenly think it does protect against sending requests, and implement sites with CSRF vulnerabilities erroneously thinking the same origin policy and CORS will protect them. By explaining first about reading responses, people quickly understand that. I then explain that it doesn't protect against sending requests, and thus state-changing handlers need CSRF protection to be implemented.
>CORS and the same origin policy are the same thing, two sides of the same coin. They express what is allow and what isn't. CORS is a configuration layer for the same origin policy, allowing you to change the default policy.
I guess I can see that, but the names of them don't really lend themselves to that understanding. The same origin policy is about same origins. If it starts allowing cross-origin communication, then it's no longer living up to its name. So I see that as it being disabled. Similarly CORS is about cross-origin sharing. If it starts blocking things, then it's not doing sharing, and thus not living up to its name.
According to Wikipedia the history backs up my understanding. It says the same origin policy was created in 1995, and CORS came later, first proposed in 2004.
https://en.wikipedia.org/wiki/Same-origin_policy
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
A soldier gets back from the front and gets a job in IT moderating internet comments.
A few months later he calls his CO and asks to be sent back to the front.
The CO asks "why would you want to do that?"
He replies, "there's a lot less fear over there."
A few months later he calls his CO and asks to be sent back to the front.
The CO asks "why would you want to do that?"
He replies, "there's a lot less fear over there."
You get downvoted, but that's pretty much spot on. I've wasted many days of my life trying to navigate around security in the browser and HTTPS everything, mostly unsuccessfully, and I only see increasingly insane lock-downs appearing as time goes on.
It feels like that the only mode of use of a computer that's allowed by security-minded folks is being a company selling shit on-line, or a customer of one. Try anything like making a simple browser UI to use some internal API, even on localhost, and you quickly end up running your own certificate authority, CORS proxy and having to buy a domain.
I mean, the very concept that the only right way to do HTTPS for internal tools is to have a public certificate on a public Internet domain, thus having to pay third parties and leaking information via certificate transparency logs, is insane when you're just doing your own stuff on your own LAN, and need to use a browser (entirely locally) or touch anything on the Internet.
It feels like that the only mode of use of a computer that's allowed by security-minded folks is being a company selling shit on-line, or a customer of one. Try anything like making a simple browser UI to use some internal API, even on localhost, and you quickly end up running your own certificate authority, CORS proxy and having to buy a domain.
I mean, the very concept that the only right way to do HTTPS for internal tools is to have a public certificate on a public Internet domain, thus having to pay third parties and leaking information via certificate transparency logs, is insane when you're just doing your own stuff on your own LAN, and need to use a browser (entirely locally) or touch anything on the Internet.
There is a good explanation here: https://stackoverflow.com/a/29167709/903011
There are always some mild arguments that CORS is better that nothing, but honestly your intuition is right, CORS is absolute nonsense.
CORS exists to keep us humble. The first time you think you understand it, your journey has only just begun.
CORS is designed to protect the server data. It's a tool that gives servers a control mechanism to tell browsers "who can access my data".
Imagine that your banking website used a standard JSON+REST API with cookie based authentication to trigger & validate a transaction request.
When a request to `fetch` or XMLHTTPRequest is made from ANY site, the browser will still populate cookies for 3rd party sites.
So without CORS, then someone might be able to create a landing page, which in the background triggers a `fetch` or `ajax` request to your bank's transaction endpoint. For 99.999% of people this wouldn't be effective because they are probably not a customer of this bank and are not logged in at the time of the request. But for some very tiny fraction of users, the browser would be tricked into populating the Cookie header from a previously created session in a different tab and would send this request.
The Origin header in the CORS preflight is a signal from the server to the browser that 'yes, this request is safe for you to construct'. This way the browser doesn't let the malicious web page "trick it" in the first place to send the bad request.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
Imagine that your banking website used a standard JSON+REST API with cookie based authentication to trigger & validate a transaction request.
When a request to `fetch` or XMLHTTPRequest is made from ANY site, the browser will still populate cookies for 3rd party sites.
So without CORS, then someone might be able to create a landing page, which in the background triggers a `fetch` or `ajax` request to your bank's transaction endpoint. For 99.999% of people this wouldn't be effective because they are probably not a customer of this bank and are not logged in at the time of the request. But for some very tiny fraction of users, the browser would be tricked into populating the Cookie header from a previously created session in a different tab and would send this request.
The Origin header in the CORS preflight is a signal from the server to the browser that 'yes, this request is safe for you to construct'. This way the browser doesn't let the malicious web page "trick it" in the first place to send the bad request.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
>So without CORS, then someone might be able to create a landing page, which in the background triggers a `fetch` or `ajax` request to your bank's transaction endpoint. For 99.999% of people this wouldn't be effective because they are probably not a customer of this bank and are not logged in at the time of the request. But for some very tiny fraction of users, the browser would be tricked into populating the Cookie header from a previously created session in a different tab and would send this request.
Are you talking about an attack where the attacker tries to control the victim's bank account by initiating a transfer? That's a CSRF attack. CORS and the same origin policy don't prevent that attack by default. The browser will still send the request the request populating the cookie. The same origin policy will prevent the evil site from reading the response, not from making the request. To protect against this attack the bank needs to implement CSRF protection (e.g. checking the Origin header).
Are you talking about an attack where the attacker tries to control the victim's bank account by initiating a transfer? That's a CSRF attack. CORS and the same origin policy don't prevent that attack by default. The browser will still send the request the request populating the cookie. The same origin policy will prevent the evil site from reading the response, not from making the request. To protect against this attack the bank needs to implement CSRF protection (e.g. checking the Origin header).
> When a request to `fetch` or XMLHTTPRequest is made from ANY site, the browser will still populate cookies for 3rd party sites.
I think this is the problem here? Just send the request without cookies if CORS doesn't allow it.
(I also think third-party cookies were a mistake in general, and it would be a good thing if they were removed. There were some plans but well, Google.)
I think this is the problem here? Just send the request without cookies if CORS doesn't allow it.
(I also think third-party cookies were a mistake in general, and it would be a good thing if they were removed. There were some plans but well, Google.)
>Just send the request without cookies if CORS doesn't allow it.
The problem is how will the browser know whether CORS would allow it or not? It could send a preflight, yes. In the current rules that's only done for complex requests, not simple requests. You seem to be suggesting preflights be sent for all requests. That would balloon the number of requests, adding RTTs, slowing down page loads.
E.g. if example.com embeds an image from imgur.com and the browser happens to have a cookie in the imgur.com cookie jar, should the browser send a preflight request first to decide whether to attach cookies to the request or not? That preflight would slow down the page load. In the current rules, the cookies are simply attached, with no preflight required for that type (simple) of request.
The problem is how will the browser know whether CORS would allow it or not? It could send a preflight, yes. In the current rules that's only done for complex requests, not simple requests. You seem to be suggesting preflights be sent for all requests. That would balloon the number of requests, adding RTTs, slowing down page loads.
E.g. if example.com embeds an image from imgur.com and the browser happens to have a cookie in the imgur.com cookie jar, should the browser send a preflight request first to decide whether to attach cookies to the request or not? That preflight would slow down the page load. In the current rules, the cookies are simply attached, with no preflight required for that type (simple) of request.
Simple requests could still work without preflight. What I suggest is, complex requests (e.g. fetch()) that don't require cookies (e. g. using credentials: "omit" [1]) shouldn't preflight either.
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
By the way, the default fetch `credentials` value ("same-origin") doesn't send cookies to third-party websites either. Why CORS still applies here is a mystery to me.
Edit: some requests can work without preflight, but there are some absurd limitations (GET/POST only, and request body can't be a JSON): https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...
And to clarify, my point here is: I think CORS is a security theater. The only part that really helps is Access-Control-Allow-Credentials (and that's only because third-party cookies are still a thing).
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
By the way, the default fetch `credentials` value ("same-origin") doesn't send cookies to third-party websites either. Why CORS still applies here is a mystery to me.
Edit: some requests can work without preflight, but there are some absurd limitations (GET/POST only, and request body can't be a JSON): https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...
And to clarify, my point here is: I think CORS is a security theater. The only part that really helps is Access-Control-Allow-Credentials (and that's only because third-party cookies are still a thing).
>By the way, the default fetch `credentials` value ("same-origin") doesn't send cookies to third-party websites either. Why CORS still applies here is a mystery to me.
There are other types of authentication besides cookies. E.g. TLS client certs. Does the browser not send a TLS client cert for fetch requests that don't send credentials? In some cases that could double the number of TLS sockets: one socket with a client cert and one socket without a client cert.
Another type of authentication is sites that only allow requests from certain source IP ranges. Or similarly, services run on a local LAN that aren't exposed to the public internet (e.g. a router's admin panel that's only accessible to devices on the LAN) or a service running locally on your machine serving on localhost. Someone might want to run a service locally and allow foo.com to make requests to it and read their responses, but block evil.com from making requests to it and reading the responses. And there might be no cookies involved with that local service, because it's running locally on the user's machine and thus doesn't need cookies to know who the user is. Of course we also need to consider DNS rebinding attacks. Those can be protected by Host header checks or Origin header checks, but Origin header checks only work for requests that send an Origin header, which aren't all requests.
>I think CORS is a security theater.
The same origin policy and CORS have 2 aspects:
1. Preventing evil.com from reading the content of email.com . I don't think this is security theater. This is very useful for security and doesn't have a bunch of confusing caveats. CORS headers can be used to allow good.com to read the content of email.com if email.com wants to allow that. That's useful for certain functionality.
2. Preventing evil.com from sending certain types of requests to email.com . This has a bunch of confusing caveats about which type of requests are allowed and which types are blocked. So this isn't super useful. However I don't think I'd call it security theater. Here's how I think this restriction was created: As browsers added more and more ways to send requests, they wanted to avoid introducing vulnerabilities to websites that were created in the past before those types of requests could be sent and that relied for security on the assumption that those types of requests couldn't be sent. So the browsers implemented preflights to make sure that these new types of requests they were creating wouldn't introduce vulnerabilities to old websites.
There are other types of authentication besides cookies. E.g. TLS client certs. Does the browser not send a TLS client cert for fetch requests that don't send credentials? In some cases that could double the number of TLS sockets: one socket with a client cert and one socket without a client cert.
Another type of authentication is sites that only allow requests from certain source IP ranges. Or similarly, services run on a local LAN that aren't exposed to the public internet (e.g. a router's admin panel that's only accessible to devices on the LAN) or a service running locally on your machine serving on localhost. Someone might want to run a service locally and allow foo.com to make requests to it and read their responses, but block evil.com from making requests to it and reading the responses. And there might be no cookies involved with that local service, because it's running locally on the user's machine and thus doesn't need cookies to know who the user is. Of course we also need to consider DNS rebinding attacks. Those can be protected by Host header checks or Origin header checks, but Origin header checks only work for requests that send an Origin header, which aren't all requests.
>I think CORS is a security theater.
The same origin policy and CORS have 2 aspects:
1. Preventing evil.com from reading the content of email.com . I don't think this is security theater. This is very useful for security and doesn't have a bunch of confusing caveats. CORS headers can be used to allow good.com to read the content of email.com if email.com wants to allow that. That's useful for certain functionality.
2. Preventing evil.com from sending certain types of requests to email.com . This has a bunch of confusing caveats about which type of requests are allowed and which types are blocked. So this isn't super useful. However I don't think I'd call it security theater. Here's how I think this restriction was created: As browsers added more and more ways to send requests, they wanted to avoid introducing vulnerabilities to websites that were created in the past before those types of requests could be sent and that relied for security on the assumption that those types of requests couldn't be sent. So the browsers implemented preflights to make sure that these new types of requests they were creating wouldn't introduce vulnerabilities to old websites.
> Does the browser not send a TLS client cert for fetch requests that don't send credentials?
I think it doesn't. From MDN: “Credentials are cookies, TLS client certificates, or authentication headers containing a username and password.”
> Another type of authentication is sites that only allow requests from certain source IP ranges.
This one can be tricky, yeah. Ideally such devices would check Origin header, but that ship has sailed I guess.
---
But I think it should be pretty safe to allow cross-origin requests that:
- don't use credentials and
- don't go to a private network.
This means that evil.com can GET https://email.com/ without CORS, but the response won't be personalized to user (so they can read the landing page but not your messages). They can also POST https://email.com/api/send, but that wouldn't do anything as again we don't include credentials.
good.com will send a request with credentials and in this case CORS should be checked indeed.
If evil.com tries to POST https://192.168.0.1/reboot we require CORS too since it's in a private net. If evil.com tries to GET https://192.168.0.1/config we don't send preflight but check CORS headers on the response before allowing to read it.
If your site is on public net and you authorize users solely by IP – that's on you.
I think it doesn't. From MDN: “Credentials are cookies, TLS client certificates, or authentication headers containing a username and password.”
> Another type of authentication is sites that only allow requests from certain source IP ranges.
This one can be tricky, yeah. Ideally such devices would check Origin header, but that ship has sailed I guess.
---
But I think it should be pretty safe to allow cross-origin requests that:
- don't use credentials and
- don't go to a private network.
This means that evil.com can GET https://email.com/ without CORS, but the response won't be personalized to user (so they can read the landing page but not your messages). They can also POST https://email.com/api/send, but that wouldn't do anything as again we don't include credentials.
good.com will send a request with credentials and in this case CORS should be checked indeed.
If evil.com tries to POST https://192.168.0.1/reboot we require CORS too since it's in a private net. If evil.com tries to GET https://192.168.0.1/config we don't send preflight but check CORS headers on the response before allowing to read it.
If your site is on public net and you authorize users solely by IP – that's on you.
> I think this is the problem here? Just send the request without cookies if CORS doesn't allow it.
Yup, very obviously a problem and it's why we got CORS :) But just because it's a problem, doesn't mean we can remove it from all browsers and call it a day, it'll break huge parts of the internet.
So in true internet engineering fashion we do what we always do, pile yet another layer on top of the stack to fix some issues from the previous layer (and add some more complications for the next (future) layer).
Yup, very obviously a problem and it's why we got CORS :) But just because it's a problem, doesn't mean we can remove it from all browsers and call it a day, it'll break huge parts of the internet.
So in true internet engineering fashion we do what we always do, pile yet another layer on top of the stack to fix some issues from the previous layer (and add some more complications for the next (future) layer).
This is mostly correct, but one thing that's worth pointing out is that CORS doesn't protect anything, but it 'loosens' the protection that the browser has by default. The S in CORS stands for sharing, not security.
Simple, if you have an iframe pointing to http://foo.test/deletesite.php, without cors that request will be done, with cookies and everything, without the user being aware of it.
AFAIKR you don't need CORS for framing, or making cross origin GET or POST. You only need it to read the response of a cross origin request and setting certain request header and body etc.
For example you can make a cross origin GET with an img tag, and a cross-origin POST with a form tag and some JavaScript.
For example you can make a cross origin GET with an img tag, and a cross-origin POST with a form tag and some JavaScript.
You're correct.
That attack you mention is a CSRF attack. CORS doesn't really protect against that. That exact attack you mention is possible if foo.test doesn't implement CSRF protection. CORS doesn't automatically provide CSRF protection.
I don't see this being a problem in situations where a customer / user can bring their own keys. The actions happens on the client-side and as long as the device or the website are not compromised it is all good.
However, this is definitely increasing the attack surface where a developer may decide for whatever reason to use production keys client-side without proxying the requests as they would normally do. I can see this being done out of convenience and performance reasons not taking into account security considerations.
However, this is definitely increasing the attack surface where a developer may decide for whatever reason to use production keys client-side without proxying the requests as they would normally do. I can see this being done out of convenience and performance reasons not taking into account security considerations.
> as long as the device or the website are not compromised it is all good
But that is THE problem. You are making yourself a huge target. The more users you have the most likely someone will attempt to hack you to use all those keys. The "client side" point is moot because the code that uses those keys comes from the server, once that's compromised all hell is loose.
But that is THE problem. You are making yourself a huge target. The more users you have the most likely someone will attempt to hack you to use all those keys. The "client side" point is moot because the code that uses those keys comes from the server, once that's compromised all hell is loose.
Also, this was always possible using a simple proxy that directly send requests to their API
Notnpossible to generate a limitee key in 2024?
The "dangerous" part of "anthropic-dangerous-direct-browser-access" is because you should never expose API keys in client code.
Unless it's the client's keys.
Or keys obtained on the client's behalf.
Or keys obtained on the client's behalf.
Generally speaking that is what OAuth should be used for with clearly defined scopes and insights in what apps are making use of the API through your account. Not an API key with full access and no limitations.
With openAI and other providers, I know you can limit the budget for a key, but that is still a pretty broad scope you are left with.
With openAI and other providers, I know you can limit the budget for a key, but that is still a pretty broad scope you are left with.
OAuth is nice when you're making an interactive in-browser SaaS. Sucks for just about any other application, in particular anything that may run headless.
Thankfully, OpenAI and the like offer actual APIs I can use for software and automation I write. And it is my right, both as a user and a developer, to let someone else write the software I'll use with my keys. It's up to me to decide if I trust that software, and suffer the consequences of a mistake. It's like the most basic way of using software, and I appreciate when I can use it like that, without having anyone insert themselves in the middle to help me stay "more secure".
Thankfully, OpenAI and the like offer actual APIs I can use for software and automation I write. And it is my right, both as a user and a developer, to let someone else write the software I'll use with my keys. It's up to me to decide if I trust that software, and suffer the consequences of a mistake. It's like the most basic way of using software, and I appreciate when I can use it like that, without having anyone insert themselves in the middle to help me stay "more secure".
Mate, the context is that Claude now supports CORS. We are talking about in-browser use.
Sure, but people are suggesting OpenAI and Anthropic should use OAuth instead of API keys. It hardly makes sense to provide both for the same functionality.
Also CORS is a PITA. Even for personal use, a browser is the most convenient environment to develop some helper tools and scripts, and it's also the only environment that - until now - could not be used with those APIs. The solution here definitely isn't moving from API keys to OAuth.
Also CORS is a PITA. Even for personal use, a browser is the most convenient environment to develop some helper tools and scripts, and it's also the only environment that - until now - could not be used with those APIs. The solution here definitely isn't moving from API keys to OAuth.
I don't think there's any reason to draw such a hard distinction between API keys and OAuth2 tokens. Either can be a subset of the other.
In a well-designed OAuth2 flow, the user should be able to select fine-grained permissions if they want to. You should be offering that same level of control for API keys. I don't see why they can't share almost all the same infrastructure. The main different is the API calls needed for OAuth2, but it's a huge value add.
You can still let people generate keys if they want to, but a well-implemented OAuth2 deployment is superior even in headless cases. Rather than having to click through the dashboard generating and copypasting keys, I can enter a short OAuth2 code in the CLI and be off to the races. Plus you get all the security benefits of token rotation, etc.
In a well-designed OAuth2 flow, the user should be able to select fine-grained permissions if they want to. You should be offering that same level of control for API keys. I don't see why they can't share almost all the same infrastructure. The main different is the API calls needed for OAuth2, but it's a huge value add.
You can still let people generate keys if they want to, but a well-implemented OAuth2 deployment is superior even in headless cases. Rather than having to click through the dashboard generating and copypasting keys, I can enter a short OAuth2 code in the CLI and be off to the races. Plus you get all the security benefits of token rotation, etc.
> Sure, but people are suggesting OpenAI and Anthropic should use OAuth instead of API keys.
No, they should offer it. As for the majority of webbrowser based use cases, it is a more appropriate solution.
No, they should offer it. As for the majority of webbrowser based use cases, it is a more appropriate solution.
Do OpenAI and Claude support OAuth? I don't think they do (except for simple bearer tokens on API calls).
Even using the client's keys it would be a good idea to give a disclaimer that their key may be stored (If that is the case) and can be accessible through nefarious means. People are very susceptible to phishing attempts etc. and this sort of business model (where you have the client supply the key and store it through the browser is a slippery slope.
Let's not train users to do things that are generally unsafe.
"We detected fraud on your account. Click here to secure your account."
"Copy and paste your secret into this box, you can trust us not to look at it."
"We detected fraud on your account. Click here to secure your account."
"Copy and paste your secret into this box, you can trust us not to look at it."
Yes, it’s like storing passwords.
Yes. It's as bad as using password managers.
Wait.
Wait.
From an application developer's perspective, the nice thing about using a passkey with a browser cookie is that you don't have to store anything sensitive. You're only guarding access to your own app with meaningless numbers. If your app doesn't store other sensitive data, the blast radius is small. There are still denial of service attacks to worry about where an attacker can use network or compute to run up your bill.
What are we guarding when building an app that uses a cloud API that costs money? Access to more compute resources. Probably a lot more than the app itself ever uses. It raises the stakes a bit. Still, in monetary terms, you're operating a vending machine that the user puts money into.
Maybe there could be some kind of protocol and workflow to securely buy a dollar of compute time from an AI vendor?
If they send some of the money to the app developer's account, it's starting to sound like an app store or micropayments system.
What are we guarding when building an app that uses a cloud API that costs money? Access to more compute resources. Probably a lot more than the app itself ever uses. It raises the stakes a bit. Still, in monetary terms, you're operating a vending machine that the user puts money into.
Maybe there could be some kind of protocol and workflow to securely buy a dollar of compute time from an AI vendor?
If they send some of the money to the app developer's account, it's starting to sound like an app store or micropayments system.
How are people using the Claude API as individuals?
Officially, individuals are not allowed to use the API.
https://support.anthropic.com/en/articles/8987200-can-i-use-...
Officially, individuals are not allowed to use the API.
https://support.anthropic.com/en/articles/8987200-can-i-use-...
They have just updated the FAQ:
> Can I use the Anthropic API for individual use?
> [Updated yesterday]
> Yes, individuals and hobbyists are welcome to use the Anthropic API. However, please note that use of the API is subject to our Commercial Terms of Service, regardless of whether you are an individual or representing a company.
Previously:
> No. Access to the API is subject to our Commercial Terms of Service and is not intended for individual use.
> Can I use the Anthropic API for individual use?
> [Updated yesterday]
> Yes, individuals and hobbyists are welcome to use the Anthropic API. However, please note that use of the API is subject to our Commercial Terms of Service, regardless of whether you are an individual or representing a company.
Previously:
> No. Access to the API is subject to our Commercial Terms of Service and is not intended for individual use.
Everyone’s their own Sole Proprietorship?
I asked someone at Anthropic about it and it turned out to be a stale page, it’s updated now and says:
“Yes, individuals and hobbyists are welcome to use the Anthropic API.”
“Yes, individuals and hobbyists are welcome to use the Anthropic API.”
Huh! That's a surprise. Especially as OpenAI has no problem with it.
[deleted]
[deleted]
I’m going to out myself, but you just do it anyway…
I’m not sure why they don’t support JWTs so we can mint limited user-specific keys instead of exposing the master key
Supabase is a great example of how to use claims to give safe client side access
Supabase is a great example of how to use claims to give safe client side access
This would unlock so many interesting use cases and protect the developer from getting a huge bill. Let me basically resell your API and abstract away any complexity to the end user. I'll charge use some % markup on top of what I pay Claude.
It was about time. We definitely wasted a bunch of time making a server side arch for pretzelai.app because claude (unlike openai) didn't have dangerouslyAllowBrowser option. No idea why this took them so long
>>why this took them so long
They were trying to have Claude code it up - but every time it got close to working, Claude would lose context and hallucinate and the code would break.
Been there too many times with Good Ol' Claude.
They were trying to have Claude code it up - but every time it got close to working, Claude would lose context and hallucinate and the code would break.
Been there too many times with Good Ol' Claude.
funny but this proves that claude is now good for code?
I can say from using the chat interface, Claude 3.5 is a top tier model for coding tasks. I used ChatGPT Pro previously, but I really find the experience of using Claude much more enjoyable overall.
Ive been coding with claude pro an app for the past month and While claude is amazing - it loses context pretty darn quick - and its ultra frustrating - look at my post history where I have written about it in some detail.
When I have the energy I should write up a detailed response - but I feel that I have experienced a lot of nefarious with Claude and how it operates.
When I have the energy I should write up a detailed response - but I feel that I have experienced a lot of nefarious with Claude and how it operates.
Claude 3.5 Sonnet is best model at coding.
For the use case of user bringing their own keys, oAuth is a much better solution. Some developer is going to hardcode their actual keys on the frontend and find out the hard way. OAuth is a more dumb-proof solution
Anthropic and all the AI vendors need to implement "Login with ___" allowing users to trust sites to use their own AI resources, similar to how Dropbox allows 3rd party access to the User's storage. Most users don't want to bother with generating and loading API keys, nor can they manage it safely.
Agree. I wish OpenRouter did something like that so that we can have only 1 vendor and app can decide themself what AI API want to use. Then user don't need to have digital wallets topped up with money for 3+ different AI vendors. Basically you want to have something similar to crypto wallet that you can easily fill with money and authorize apps.
Maybe for internal development, but definitely not for a user-facing app. Making less impactful of a change. But still nice
I'm thinking it enables apps where users can bring their own keys without exposing it to my server.
That's the only good use of this but I bet people will end up leaking their keys being stupid with it.
That's on them though. It's nice to have an option where the third party app just provides its value-add, instead of insisting on being the first party.
That's what I've done for my chatgpt UI - I store the API key and any other user config in local storage.
> if you embed your API key in your client code, anyone with access to that site can steal your API key and use it to make requests on your behalf.
Great. Anyone know a search engine to find these 'free usage' keys?
Great. Anyone know a search engine to find these 'free usage' keys?
I think https://publicwww.com/ could do the trick?
Great to see CORS support added! This will make integrating Claude's API into client-side apps much smoother.
I'm really glad to see this. Last week, when I upgraded the Anthropic TypeScript SDK from 0.23.0 to 0.26.0, my browser extension (chathub.gg) broke because they completely banned the use of this SDK in browsers!
I mean, you could have just made a quick proxy with a little express server to get around this anyways. But I shouldn't be complaining, it's good that they did this.
Edit: of course, I just realized that people may not want their api key being sent to your server.
Edit: of course, I just realized that people may not want their api key being sent to your server.
Claude is growing strong with these new features
> I must strongly advise against making direct API calls from a browser, as it exposes your API key and violates best practices for API security.
Hilarious that even the LLM warned against this
Hilarious that even the LLM warned against this
Depends how you do this. If you allow users to configure their own key, they basically end up using https to communicate the API key directly to the party that issued it. Not much of a risk of leakage there and very common with e.g. browser and editor extensions written in javascript. In a browser, you need the server to be setting CORS headers for this to work.
Provisioning some key to your users so they can then pass it on via a client side API call would indeed be more risky. Don't do that. But if it's their own key it's all fine.
Provisioning some key to your users so they can then pass it on via a client side API call would indeed be more risky. Don't do that. But if it's their own key it's all fine.
I see three problems with this:
1. From a product perspective, this is like going to a restaurant to get dinner but having to bring your own kitchen utensils, food and cooking your dinner yourself.
2. Anything running in a browser is inherently insecure - what's the guarantee that the site where you're pasting your key doesn't have some incredibly stupid security flaw and your key gets leaked?
3. Even if there are no vulnerabilities, you're still pasting your code in a random form somewhere on the web. All it takes is an ajax call or a websocket and someone, somewhere has your key.
1. From a product perspective, this is like going to a restaurant to get dinner but having to bring your own kitchen utensils, food and cooking your dinner yourself.
2. Anything running in a browser is inherently insecure - what's the guarantee that the site where you're pasting your key doesn't have some incredibly stupid security flaw and your key gets leaked?
3. Even if there are no vulnerabilities, you're still pasting your code in a random form somewhere on the web. All it takes is an ajax call or a websocket and someone, somewhere has your key.
Sure, but this approach also has a lot of benefits, and there's a market segment that really appreciates those features, one that you likely aren't even serving right now, and which you could capture nearly for free by just adding a form field that stores an API key client-side and forwards it to requests to the API vendor. No operations costs for you at all.
This is true: you do have to trust the site author that you are pasting your key into not to steal it.
For my https://tools.simonwillison.net/haiku thing I deliberately kept the code as simple as possible: if you know basic JavaScript you can view source and confirm that your key is not being stolen.
The code is also open source, so you can run a copy on your own hosting if you want to.
If you don’t trust that then I guess you don’t get to use my tool to write haikus about your dog!
As for usability: obviously if you want your thing to be used by people who don’t know how to pay for their own API key you should use a different solution.
I mainly want to ship cool demos that are trivial to host and that other people can try out without bankrupting me, so I’m really excited about this.
For my https://tools.simonwillison.net/haiku thing I deliberately kept the code as simple as possible: if you know basic JavaScript you can view source and confirm that your key is not being stolen.
The code is also open source, so you can run a copy on your own hosting if you want to.
If you don’t trust that then I guess you don’t get to use my tool to write haikus about your dog!
As for usability: obviously if you want your thing to be used by people who don’t know how to pay for their own API key you should use a different solution.
I mainly want to ship cool demos that are trivial to host and that other people can try out without bankrupting me, so I’m really excited about this.
Focused gaze peers out,
Framed by thoughtful, steady eyes,
Seeking new insights.
A brushing moment, Simple tools, focused rituals, Cleansing, renewing.
Stark white cylinder, Held aloft, its purpose clear, Clean and functional.
Analog timepiece, Held in a steady hand's grasp, Marking life's rhythm.
A brushing moment, Simple tools, focused rituals, Cleansing, renewing.
Stark white cylinder, Held aloft, its purpose clear, Clean and functional.
Analog timepiece, Held in a steady hand's grasp, Marking life's rhythm.
I might be biased, but I think there's room for a service that can make BYOK frictionless. Best of both worlds, unless you're a money sucking corporation trying to turn a purchase once product into a subscription service because late stage capitalism.
Also from the product side, if you're making client side requests with users' own keys, doesn't that also mean that your LLM prompts are visible to the user if they just inspect their network requests?
If your app is largely just a wrapper around a neat prompt, it means I can just go and copy the prompt and use it myself and save the fees on your app.
Your app has to really be a valuable UX wrap over the calls in that case, or catering to a nontechnical audience.
If your app is largely just a wrapper around a neat prompt, it means I can just go and copy the prompt and use it myself and save the fees on your app.
Your app has to really be a valuable UX wrap over the calls in that case, or catering to a nontechnical audience.
> Your app has to really be a valuable UX wrap over the calls in that case, or catering to a nontechnical audience.
There is space on the market for such apps, too. Lots of space, in fact, as the idea of making software tools instead of toys seems to be forgotten. "Bicycle for the mind" got stolen some years ago, and it's time to get it back.
And frankly, an app that's "largely just a wrapper around a neat prompt", is something I consider to fall somewhere between Fischer-Price copycat toy and a direct scam. It's definitely not a tool empowering people, if it can be replaced with "paste this into ChatGPT config" (or "paste this into this more configurable bring-your-own-key frontend for ChatGPT").
There is space on the market for such apps, too. Lots of space, in fact, as the idea of making software tools instead of toys seems to be forgotten. "Bicycle for the mind" got stolen some years ago, and it's time to get it back.
And frankly, an app that's "largely just a wrapper around a neat prompt", is something I consider to fall somewhere between Fischer-Price copycat toy and a direct scam. It's definitely not a tool empowering people, if it can be replaced with "paste this into ChatGPT config" (or "paste this into this more configurable bring-your-own-key frontend for ChatGPT").
>It's definitely not a tool empowering people
I agree. My point is that as a business the only moat they'd have is to not do client side requests, in order to hide the prompt.
I agree. My point is that as a business the only moat they'd have is to not do client side requests, in order to hide the prompt.
Your analogy in 1. sounds off to me. It’s definitely like bringing your own food, but the already well equipped kitchen and chefs will prepare it for you.
From a security standpoint it's no different than a password form except you're sharing one company credential with another. The issue is not html forms though, it's that you might trust Anthropic more than you do the hot new website built yesterday.
Bit of an odd warning though, considering how half the internet works. I suppose the warning is missing some context.
It is a bad idea to give your API key directly to web services you don't know or trust. For those situations, OAuth with fine-grained scopes would be more suitable.
If it is just your own web app, and you have an input for a key, I don't really see the issue.
If it is just your own web app, and you have an input for a key, I don't really see the issue.
[deleted]
ellellem(3)
> It’s fine for internal tools exposed to trusted users,
No, not really?
> or you can implement a “bring your own API key” pattern where users supply their own key to use with your client-side app.
This is a valid use-case, even if it breeds unsafe patterns (just allow random site/code on the internet impersonate you and spend money on your behalf).
But it's not really worse than how 3rd party integrations generally do that anyway.
No, not really?
> or you can implement a “bring your own API key” pattern where users supply their own key to use with your client-side app.
This is a valid use-case, even if it breeds unsafe patterns (just allow random site/code on the internet impersonate you and spend money on your behalf).
But it's not really worse than how 3rd party integrations generally do that anyway.
Why isn’t it OK for internal tools with trusted users?
It’s functionally the same as saying “hey coworker, here’s an API key you can use, it’s billed to the company”.
It’s functionally the same as saying “hey coworker, here’s an API key you can use, it’s billed to the company”.
I suppose - my general reaction is that use of such magic api keys are difficult to audit, revoke etc - and there's the constant risk they will leak.
They could do a system where you can create one API key with a budget for a site, and that's it, that would be enough, but until they have that budget system, it's not really a good approach
1. A live transcription and translation app that uses microphone input. This is useful for watching proprietary content and facilitating communication.
2. An app that translates SRT subtitles into various languages.
I opt for the "bring your own keys" model for two main reasons:
1. Low maintenance: As a professional software developer, I already maintain a lot of software, and the last thing I want is to maintain my side projects. My goal is to write and distribute these apps so they continue working without requiring constant attention from me.
2. Low cost: This model allows me to distribute the apps without ads. By having users provide their own keys, I can keep operational costs down and avoid the need for monetization through advertising.
This approach enables me to create and share useful tools while keeping both my maintenance burden and user costs to a minimum.