For anyone interested, the DELETE API already exists, but you need a "special" developer token fetched from music.apple.com and Music-User-Token accordingly to call it. Steps are as follows: visit music.apple.com and sign in, then go to the console of your browser input MusicKit.getInstance().musicUserToken to get your user token input MusicKit.getInstance().developerToken to get the privileged developer token Then you could try the DELETE API curl --location --request DELETE 'https://amp-api.music.apple.com/v1/me/library/songs/{songId}' \ --header 'Music-User-Token: {The User Token you got}' \ --header 'Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IldlYlBsYXlLaWQifQ.eyJpc3MiOiJBTVBXZWJQbGF5IiwiaWF0IjoxNjQ2NDM1NTgxLCJleHAiOjE2NjE5ODc1ODF9.Ob5bfZBWLDlDkR4r5fNXIjp1Y1G0qY5mP9MVBm1mDFjG701_6AcZS6nwjk-CMJE2b8VLv1JWxKR5j5BDkKxQ7w' For more details you could visit my another post

The privileged token could also be used to wipe a user's music library maliciously Users sign in to their Apple Music account on any apps or websites without worrying security issues because Only Apple official apps and website could delete user's content Users could review the info and then grant permission before they sign in 3rd party apps But that github project has bypassed all the protections mentioned forehead by using the privileged token, and users could hardly notice it. Therefore anyone using their app has a potential risk to lose all his/her content in the library. And if it does happen, Apple will be blamed for not patching this vulnerability and not stopping people abusing it. I think a warning letter should be sent to that github project. Right now they are promoting their app and receiving sponsorships.

I noticed Apple has added verification to the token that music.apple.com is using, i.e added root_https_origin to the token payload. For anyone interested, please visit the link below: https://jwt.io/#debugger-io?token=eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IldlYlBsYXlLaWQifQ.eyJpc3MiOiJBTVBXZWJQbGF5IiwiaWF0IjoxNjQ4NzAyODQ1LCJleHAiOjE2NjQyNTQ4NDUsInJvb3RfaHR0cHNfb3JpZ2luIjpbImFwcGxlLmNvbSJdfQ.YKJYticxSydqqyApFTAJjYURls4Oqb5b0VjbCxqJsYIPU4CtI1tCsk9697VOmwQdhIIsTpYprRcoA1qj_72RHw But the Cider app still managed to find a work around to bypass the verification. The proof is as follows: curl --location --request GET 'https://api.cider.sh/v1/' \ --header 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Cider/1.1.573 Chrome/96.0.4664.110 Electron/16.0.8 Safari/537.36' \ --header 'Host: api.cider.sh' The token returned could still be used to call the "https://amp-api.music.apple.com" endpoint. I appreciate Apple listen to our voices and respond quickly. But please do one more step to enforce the API endpoint so that token without root_https_origin in the payload cannot be used. Or perhaps there might be better ways to eliminate this workaround.

I appreciate Apple has made some improvement to fix this issue but there is still a workaround left behind. For more info please see my newest answer or visit this link.