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

91–100 of 173 posts

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

#91

Post by Jarwain »

samstave wrote: post #86
diggan wrote: post #78

Earlier quoted context omitted.

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

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

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

#92

Post by perpil »

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…

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.

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

#94

Post by vdfs »

_pdp_ wrote: post #68

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

Also, this was always possible using a simple proxy that directly send requests to their API

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

#95

Post by easton »

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

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.

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

#96

Post by 1234letshaveatw »

alex_suzuki wrote: post #64
shaneos wrote: post #59

Earlier quoted context omitted.

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.

I think it was probably the gratuitous inclusion of the url

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

#97

Post by swah »

simonw wrote: post #31
axegon_ wrote: post #30

Earlier quoted context omitted.

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…

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…

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.

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

#98

Post by simonw »

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

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

#100

Post by Thorrez »

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…

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

Post reply on HN