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

61–70 of 173 posts

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

#61

Post by notpushkin »

eejjjj82 wrote: post #57
saagarjha wrote: post #53

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

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…

> 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.)

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

#62

Post by TheCapeGreek »

TeMPOraL wrote: post #37
TheCapeGreek wrote: post #35

Earlier quoted context omitted.

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

> 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", i…

>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.

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

#63

Post by notpushkin »

londons_explore wrote: post #54

> 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?

I think https://publicwww.com/ could do the trick?

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

#64

Post by alex_suzuki »

shaneos wrote: post #59
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 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 th…

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.

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

#65

Post by kreetx »

simonw wrote: post #29
ellellem wrote: post #26

Earlier quoted context omitted.

[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 i…

Yup, for development purposes I've used a self-generated root and signed certificates for it (and I also understand the risks).

Though, on topic, Claude enabling access for browsers adds nothing specific to this risk - it's a generic risk for any TLS connection.

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

#66

Post by breck »

saagarjha wrote: post #53

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

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."

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

#67

Post by hhh »

InsideOutSanta wrote: post #40
KeplerBoy wrote: post #17

Earlier quoted context omitted.

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.

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

This is also pricing for customers, not what it actually costs to run.

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

#68

Post by _pdp_ »

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.

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

#69

Post by danw1979 »

axegon_ wrote: post #30
jillesvangurp wrote: post #21

Earlier quoted context omitted.

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…

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.
Post reply on HN