Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude's API now supports CORS requests, enabling client-side applications

simonwillison.net

Post reply on HN
Print view View original

21–30 of 173 posts

Re: Claude's API now supports CORS requests, enabling client-side applications

#21

Post by jillesvangurp »

jdenning wrote: post #9

> 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

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.

Re: Claude's API now supports CORS requests, enabling client-side applications

#23

Post by jillesvangurp »

creesch wrote: post #19
unglaublich wrote: post #6

Earlier quoted context omitted.

Unless it's the client's keys. 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.

Do OpenAI and Claude support OAuth? I don't think they do (except for simple bearer tokens on API calls).

Re: Claude's API now supports CORS requests, enabling client-side applications

#24

Post by simonw »

jillesvangurp wrote: post #23
creesch wrote: post #19

Earlier quoted context omitted.

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.

Do OpenAI and Claude support OAuth? I don't think they do (except for simple bearer tokens on API calls).

They don’t - which is a shame, I’d love to be able to bounce a user through an OAuth flow and then make API calls using their token such that their activity is billed to them directly.

Re: Claude's API now supports CORS requests, enabling client-side applications

#27

Post by creesch »

jillesvangurp wrote: post #23
creesch wrote: post #19

Earlier quoted context omitted.

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.

Do OpenAI and Claude support OAuth? I don't think they do (except for simple bearer tokens on API calls).

They don't, but they probably should imho. I was just talking about best practices in general.

Re: Claude's API now supports CORS requests, enabling client-side applications

#28

Post by bboygravity »

afiodorov wrote: post #10

I love making web apps where users bring their own keys. This approach combines the best of both worlds: the convenience of distributing executable files and the benefits of open source. So far, I have developed two web apps: 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 in…

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.

Re: Claude's API now supports CORS requests, enabling client-side applications

#29

Post by simonw »

ellellem wrote: post #26
simonw wrote: post #22

Earlier quoted context omitted.

Right - MITM isn’t a threat here.

[flagged]

Don’t try to support your arguments by pasting paragraphs of text from ChatGPT.

That said, there is a little nugget of useful information in there: “To do this, they install a corporate root certificate on all employee devices.”

This is true: if you are using a device which has had a root certificate installed on it you are vulnerable to MITM attacks. I would argue that your employer stealing your Anthropic API key is a pretty low risk compared to everything else that is wrong with that scenario!

Your original message above also mentioned coffee shop WiFi: that’s not a threat here. Your coffee shop has not installed a root certificate in your device.

Re: Claude's API now supports CORS requests, enabling client-side applications

#30

Post by axegon_ »

jillesvangurp wrote: post #21
jdenning wrote: post #9

> 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

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 pa…

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.

Post reply on HN