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

111–120 of 173 posts

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

#111

Post by farco12 »

meiraleal wrote: post #101
samstave wrote: post #87

Earlier quoted context omitted.

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

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.

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

#112

Post by simonw »

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…

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

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

#113

Post by Thorrez »

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…

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

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

#114

Post by dceddia »

saagarjha wrote: post #73
barrkel wrote: post #55

Earlier quoted context omitted.

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

Ok but like why would you pass cookies along

Just to add to the sibling comment - you don’t get a choice to pass cookies or not, the browser just includes them automatically.

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

#116

Post by BrandiATMuhkuh »

bboygravity wrote: post #28
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 a…

What's the name of the extension. I was looking for something like this recently

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

#117

Post by notpushkin »

Thorrez wrote: post #110
notpushkin wrote: post #61

Earlier quoted context omitted.

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

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

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

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

#118

Post by e12e »

simonw wrote: post #98
e12e wrote: post #84

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

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

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.

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

#119

Post by jasondigitized »

ripped_britches wrote: post #99

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

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.

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

#120

Post by slowmotiony »

afiodorov wrote: post #50
purple-leafy wrote: post #48

Earlier quoted context omitted.

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?

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

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