Con le estensioni / strumenti del browser di oggi non è facilmente possibile per un utente modificare le impostazioni html / css di un sito web e così abilitare alcuni pulsanti disabilitati, ecc ... per accedere alle aree non consentite?
Sì, è possibile manipolare qualsiasi cosa nel lato client, che include HTML, CSS e JavaScript. Tuttavia, il codice lato client originale è memorizzato nel server e, sebbene sia possibile manipolarlo, se non si ha accesso al server non è possibile salvare le modifiche. L'aggiornamento del browser implica essenzialmente la richiesta di una nuova copia del codice lato client, quindi tutte le modifiche alla copia locale scompariranno.
Come per le aree riservate, diciamo ad esempio un modulo di accesso. Sebbene sia possibile modificare i colori e / o le dimensioni della casella di immissione della password, il codice che convalida se la password è corretta risiede sul server, non si ha accesso ad esso e le modifiche del lato client non lo influenzano, quindi non c'è niente di cui preoccuparsi.
Supponendo che la tua dichiarazione di abilitazione di pulsanti o collegamenti precedentemente disabilitati tramite gli strumenti di dev del browser significhi che l'utente possa accedere a un'area dell'applicazione che altrimenti non avrebbe, ti riferisci a ciò che è noto come vulnerabilità delle autorizzazioni . In questo caso, la sicurezza dipende dal livello di presentazione per rafforzarlo, il che, come sai, è facile da aggirare.
La migliore difesa contro questo è eseguire la tua autorizzazione sia nel livello di presentazione (browser) che nel livello aziendale (server). Convalida sempre e autorizza le richieste degli utenti sul server. Di solito, nel browser si consiglia di migliorare l'esperienza dell'utente (ad esempio, non mostrarmi collegamenti a funzioni che non posso fare perché è solo un rumore visivo da analizzare) e nasconde funzionalità che altrimenti verrebbero inavvertitamente comunicate. Mostra solo ciò che devi, ma convalida e autorizza tutto sul server.
Dipende da cosa contengono questi file.
Ad esempio, supponiamo che la persona A abbia un sito web. Questo sito Web ha un collegamento (o pulsante o qualsiasi altra cosa) ad una pagina web che dovrebbe essere disponibile solo per gli amministratori, con elementi usati nel debug (come ad esempio la cancellazione del database). Quando il sito va in diretta, decide che invece di rimuovere il link e il codice di debug, commenta solo il link e lascia il debugging. Boom! Puoi immaginare che chiunque possa vedere il commento visualizzando la sorgente della pagina in qualsiasi browser.
Ma poi di nuovo, questo tipo di cose accadono solo a causa di errori umani (e forse di stupidità). Io per primo non ho mai visto questa roba nella mia vita e sarei stupito se mai lo avessi fatto.
Se costruisci un sito web giusto e non lasci brutte cose nel tuo codice, allora stai tutto bene.
Quando visiti un sito web ricevi solo file che descrivono ciò che vedi sullo schermo. Per quanto riguarda la parte funzionalità (scripting), questi sono disponibili in due diversi gusti. Prima c'è lo scripting lato client e, a meno che tu non voglia farti del male, non c'è molto che tu possa fare con esso. In secondo luogo, c'è lo scripting lato server che contiene codice per la connessione al database e il recupero di informazioni e simili, ma tu MAI ricevilo (secrets: P).
Alla fine, ci sono possibilità che le cose corporee accadano da html e css ma tu davvero, davvero, davvero devi uscire per permetterle.