Re^2: Pass hard coded param CGI post

this pattern of HTML form + cgi processor is inferior to using a modern JavaScript async call to send the data to a RESTful API endpoint (like /cgi-bin/rob/gfgf with method=DELETE, encoded as application/json

I do have to stop and take issue with this. A key principle on the Web is graceful degradation. Nearly all interactive browsers support forms, including such oddballs as Lynx and other curses-based browsers that do not require a graphical display. You can have a fancy JavaScript frontend, but you should still have basic forms — perhaps the CGI form processor translates the form submission to a RESTful request — for browsers that do not support JavaScript and users that choose not to run JavaScript.

That last note is a legitimate choice no matter how many hipster Web developers whine about it — nearly all client-side Web security exploits in the modern era have depended 100% on JavaScript to run. Disabling JavaScript is very much legitimate security advice, unless of course you want your files ransomwared.

Comment on Re^2: Pass hard coded param CGI post

Replies are listed 'Best First'.
Re^3: Pass hard coded param CGI post by Anonymous Monk on Jun 30, 2020 at 01:19 UTC
nearly all client-side Web security exploits in the modern era have depended 100% on JavaScript to run^{[citation needed]}	[reply]
Re^4: Pass hard coded param CGI post by jcb (Parson) on Jun 30, 2020 at 02:20 UTC
Then provide some counterexamples. Even Internet Explorer (as far as I know, the only browser to ever be exploitable with only plain HTML) had those problems only in the late 1990s. All of the recent exploits I remember off the top of my head have been JavaScript JIT bugs.	[reply]
Re^5: Pass hard coded param CGI post by Your Mother (Archbishop) on Jun 30, 2020 at 08:32 UTC
Just dog piling IE: it was exploitable at one time or another in every conceivable way, including a character set attack.	[reply]


Think about Loose Coupling
	PerlMonks