could be improved by a lot https://tsplay.dev/mbb83m
#Assessing the Quality of My Program
atomic patrol
a few things I noticed:
- that main
fetchUsersfunction does way too much: it fetches users, fecthes settings, and writes all of it to a file; that's too much - you are not reusing the funciton you created, especially the ones that creates signed requests
- move your config outside of the function, make it global, or apss it as parameters; this makes your code more easily reusable
- the handle errors where it makes sense, network errors inside of the fetch functions, error logging at the top level
- create types for the elements you need; in your version,
usersandsettingsand never given a type, and it does not help - use typescript inference where you can, no need to specify the return type of every function, especially when it's obvious
@next warren
Yes
Playground link was too big to fit, had to ise an URL shortener
atomic patrol
don't know
actually it comes from your code
const data = new URLSearchParams({
nonce: nonce,
username: '[email protected]',
password: 'test'
});
const response = await fetchWithCookies(
'/api/users', {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify(data)
});
think you need to call the .toString() on it first
but I have no idea what the API accepts as body, so only you have the answer
small hornet
don't know
actually it comes from your code
```ts
const data = new URLSearchPara...
Why is there a nonce in the request? Is this actually a csrf?
afaik a nonce is usted in html header (valid for any resource being loaded from backend).
You can use it in the headers Content-Security-Policy: script-src 'nonce-8IBTHwOdqNKAWeKl7plt8g==' which would only secure <script src=...>
And you can use it directly in several elements
<script nonce="...">In which every respond from backend has to use the same nounce, otherwise the file will be considered invalid. This can be used to avoid 3rd party libraries to add images, scripts etc. into your site.
You have no access in JS to the nonce when set as header (afaik?).
But when using it directly in a request, handwritten, this makes no sense, because the browser enforces nonce based on the element (or whatever was specified in the header).
I think there is a confusion of nonce with csrf, which is used in requests but not when you do the request by hand, its more meant when the html is serverside rendered, where you add a csrf token inside a form (hidden from ui, but the value will be transmitted nontheless).
Having it in requests is pointless as this doesnt help you to protect your api from not being used by the provided gui.
In cases where you have a independent api that doesnt directly produce a gui (e.g. html) but serves data (e.g. xml/json) then you need other techniques to secure your api, e.g. easiest way is to fingerprint your clients
twin wagon
You're mostly on point, but let me help clarify a few things about how nonces, CSP, and CSRF tokens work.
A nonce (number used once) is typically used in the Content-Security-Policy (CSP) HTTP header to allow inline scripts or styles that match a specific random value. For example:
Content-Security-Policy: script-src 'nonce-8IBTHwOdqNKAWeKl7plt8g==';
This tells the browser to only execute scripts that have a matching nonce attribute:
<script nonce="8IBTHwOdqNKAWeKl7plt8g=="> ... </script>
Nonces are per-response, meaning the backend needs to generate a fresh nonce for each HTML response and ensure it’s consistent across the CSP header and the inline elements. This helps block unauthorized scripts—especially from third-party sources—from being injected and executed.
You're also correct that JavaScript running in the browser can’t access the nonce set in the CSP header—this is intentional for security.
Now, when you mention "handwritten requests," you’re right that manually including a nonce doesn’t really do anything. The nonce only makes sense in the context of a browser enforcing CSP rules, not when making API requests via fetch or curl, for example.
That’s where CSRF tokens come in. These are used to prevent cross-site request forgery, typically in server-rendered HTML forms. The token is added as a hidden field in the form and validated by the backend when the form is submitted. They're meant for form submissions, not for protecting APIs.
When your frontend and backend are decoupled—say, a React frontend hitting a REST API—CSRF protection becomes less useful. In those cases, you typically use authentication tokens, CORS policies, and possibly client fingerprinting or rate limiting to protect your API.
So in short:
Use nonces with CSP to secure inline scripts in HTML.
Use CSRF tokens to secure form submissions in traditional apps.
For APIs, go with tokens, CORS, and auth headers—nonces and CSRF won’t help much there.
atomic patrol
What I'm trying to say is that I simply took your code and re-wrote it in a more elegant way
I haven't made any changes to how it works and what it does; especially about the nonce others were talking about
atomic patrol
the check on the response status (ok) is definitely needed
as for validating the content of the body, I'd say it's up to you
cbut shouldn't imo be necessary since the API is supposed to return you clean and valid data
unless you have clear reasons to believe it won't