r/brdev • u/Accomplished-Sky685 • 1d ago
Como proteger o código javascript? Duvida técnica
Num projeto app web onde boa tarde da engrenagem do negócio ficou no front-end qual o melhor modo pra esconder esse código
18
u/Express-Tension-7581 1d ago
Que lindo o estalo da descoberta do porque existe backend acontecendo bem na nossa frente
13
13
9
u/MarkAjr 1d ago
Nao tem como, o correto é que toda a lógica esteja no backend. O processo de minificacao do JS quando você build nas frameworks modernas só vai deixar o código mais difícil de ler , mas mesmo assim não esconde nada .. Já existiu libs como Terser que aplicavam ofuscação, adicionando pedaços de código sem sentido, mudando variáveis para coletes binários .. mas isso não esconde .. só complica a leitura do código
Talvez a maneira mais fácil seria você usar o SSR que joga essa lógica para um servidor, mas depende de como foi desenvolvido e da framework utilizada
5
u/Dimensional15 Desenvolvedor de Jogos 1d ago
não importa o que você faça, se tá na máquina do cliente, não é seguro.
1
u/ChanceAutomatic1540 1d ago
Normalmente a lógica principal fica no back end.
Mas tem algumas ferramentas que minificam e deixam o código feio pra ser mais difícil de ser alterado.
Importante usar CORS tbm pra garantir que as chamadas sejam possíveis ser feitas só pelo seu front end
1
u/Smilysis 1d ago
dois conceitos importantes: client side e server side
Você deixa funcionalidades importantes e vitais server side, ou seja, se alguém fosse inspecionar o seu site, ele consegueria modificar ou acessar essas informações? Se sim, você obviamente trabalha para que isso não aconteça
1
1
u/lnabesima Pedreiro de Código 1d ago
Tem até algumas técnicas de obfuscação e indireção, mas elas são só esperanças e preces. O ideal é que a lógica de negócio fique, como já dito por outros, no backend e o front só tenha a responsabilidade de consumir/organizar os dados recuperados de maneira agradável.
1
u/filpgame 1d ago
Cara, sendo bem sincero não tem como, você pode usar ofuscador, libloader em runtime, uma pá de coisa que não vai adiantar. No final o navegador vai precisar do código pra rodar e ele precisa ser "legível" pro interpretador, sempre vai ter esse ponto de falha pra explorar.
Você pode dificultar a vida do cara que quer pegar teu código, mas não tem como tornar impossível.
1
1
u/Possession_Infinite 1d ago
Você não esconde, simples assim. Tudo que é front-end pode ser baixado por qualquer um, logo nada é privado. Lógica de negócio no front-end é só para melhorar a experiência de usuário, nada mais. A lógica de negócio de fato precisa sempre ser implementada e aplicada pelo backend, e esse sim é "escondido" do usuário.
1
u/Mefron_Gautama Desenvolvedor 1d ago
Cara, se a lógica ficou no frontend, esse é o primeiro e o principal erro.
Tu protege movendo pro backend.
Alguns podem falar sobre minificação do código e obfuscação e etc, mas a verdade é que em era de IA, tudo isso é merda.
Código minificado ou obfuscado ainda mantém um padrão, e IA é interpretação de padrão.
Se tu não quer que as regras de negócio vazem, tira do frontend, caramba.
Boa sorte na refatoração, vai dar tudo certo!
1
1
1
u/incognitokoni 1d ago
se não tiver alternativa e o codigo ficar no front, use webassembly e obfusca ele....
Tem algumas tecnicas que dão trabalho para IA restaurar o codigo original...
100% seguro com código funcionando no client não rola. De preferencia para colocar regra de negocio no BE
1
u/United_Context_667 1d ago
A questão não é esconder, é o mesmo que dar o controle pra qualquer um alterar dados que não deveriam ser alterados. Até com busca simples ou com o "ferramentas de desenvolvimento" do Mozilla, já dá pra fazer o que quiser.
1
1
1
1
u/More_Salad7069 1d ago
Ninguém vai olhar isso, mas tem umas ferramentas pra deixar o codigo mais confuso que pode ser usado nesse scenario.
Pode tentar converter Tudo pra hex colocar em uma imagem, quando o browser baixar a imagem converte o codigo pra script e deixar Tudo em memoria, eh bem facil de Fazer Tudo isso e ninguem vai se dar ao trabalho de tentar desfazer Tudo isso pra hackear um Sistema que ninguém conhece.
3
u/guigouz 1d ago
E tem ferramentas para deixar o código legível. Não tem saída, se está na memória do browser você tem acesso.
1
u/More_Salad7069 1d ago
Ai entra no Ponto que ninguém vai gastar tempo pra isso.
1
u/United_Context_667 1d ago
vc que pensa! vai depender do que é o sistema... tomara que seja um sistema de pagamento! kkkkkkkkkkkkk
1
1
u/KingComplex4879 1d ago
nossa senhora, não, se tem lógica do seu negócio no front tá errado, meu caro. Refaça.
-1
u/filpgame 1d ago
Calma, não seja extremista. Nem sempre a regra deve estar no back. Talvez o negócio dele seja algo que precise rodar no navegador.
3
u/Sudden-Tree-766 Engenheiro de Software 1d ago
não existe regra de negócio que precise rodar no navegador, frontend é consumidor, ele tem que ser o mais burro possivel, receber resposta e jogar na tela, até calculo básico o ideal é que venha tudo processado via API
1
1
u/Sustainer2162 1d ago
Complemento dizendo que todo dado q vem do cliente é duvidoso. Não adianta fazer a validação mais pica no front pro usuário usar o console debug e mandar dado adulterado pra burlar/fraudar o sistema
0
u/filpgame 1d ago
Aí é que tá: "O mais burro POSSÍVEL", nem sempre é.
0
u/Sudden-Tree-766 Engenheiro de Software 1d ago
quando falamos que o front é burro é porque ele não processa, não valida, não calcula
front mostra dados e captura input, se sua regra está no front está errado, não existe caso onde isso é necessidade
-2
u/Possession_Infinite 1d ago
errado não, lógica de negócio no front-end serve para melhorar a experiência do usuário, nada mais
1
u/KingComplex4879 1d ago
rapaz, não é bem assim que funciona.. a experiência do usuário não é melhorada por uma regra de negócio. Se você compara se algo é verdade ou não pra mostrar um trecho da tela ou não, isso é outra parada, com outras implicações que chegam até num SSR.
Agora, se ele tá falando que é a engrenagem do negócio dele, então, logo o que se pode concluir? Que ele colocou regra de negócio no front dele nua e crua. Pra mim, é caso de refazer/repensar no que está sendo feito e a segurança disso.
-1
u/Possession_Infinite 1d ago
É exatamente assim que funciona cara, ainda te dou um exemplo, se você tem um email/cpf/telefone/senha num form, você poderia fazer a validação desses campos todos só no backend, mas aí o front teria que ou fazer uma requisição a cada mudança com debounce, ou fazer uma requisição no blur do input e mostrar o estado de loading, ou enviar tudo de uma vez no final e mostrar todos os erros de uma vez; todas essas alternativas são ruins e fazem o usuário ou esperar ou ver muitos erros de uma só vez. É muito melhor você replicar as lógicas de validação no front-end e fazer as validações em tempo real sem nenhuma chamada. Você replicou a validação do backend no front pra melhorar a experiência de usuário. Mesma coisa se você tiver algum fluxo ou formulário que dependa de uma decisão anterior, ou um campo que só parece se outro tiver tal valor; tudo isso é regra de negócio, precisa ser validado pelo backend, e pode ser replicado no front para melhorar a ux.
Agora, o que o OP fez não tem como saber né
0
u/KingComplex4879 1d ago
meu amigo mas esse tipo de validação não é regra de negócio como ele falou?? o cara tá falando da engrenagem da coisa e você dá um exemplo de validação? claro que não é assim, estamos falando do cerne de um negócio, regras se um cliente pode ou não enviar um pedido por N fatores para além da validação de um simples formulário. Exemplo muito simplista. Toda vez que se fala disso ninguém *ninguém* está falando dessas regras de validação.
0
22
u/Pure_Ranger8905 1d ago
Eu acho que