DEV Community: Matheus Silva

5 lições de segurança que aprendi estudando um host temporário de arquivos

Matheus Silva — Thu, 15 Oct 2026 18:18:49 +0000

Estudei como funciona um projeto open-source de host temporário de arquivos, o Waifuvault, e criei um utilizando Laravel. Neste artigo, vou compartilhar 5 lições de segurança que são essenciais nesse tipo de aplicação e um pouco da experiência de criar esse projeto utilizando Laravel.

Não confie no que é enviado pelo usuário

Provavelmente você já deve ter ouvido essa frase e nesse tipo de aplicação, é importante fazer a validação dos dados enviados pelo usuário, como nome do arquivo, headers como Content-Type e Content-Length que são variáveis importantes nesse contexto.

Dado um cenário em que é enviado um arquivo de 10mb, o servidor precisa verificar o tamanho real recebido para garantir que não ultrapasse o limite permitido pela aplicação.

Uma forma de se prevenir isso é durante o recebimento de arquivos por streaming verificar os bytes recebidos conforme for armazenando. Se o limite for atingido, ocorrer uma falha ou divergência, o upload deve ser rejeitado e o arquivo parcial que estava sendo salvo deve ser removido, evitando registros órfãos no sistema.

Também é uma boa prática alterar o nome do arquivo para algo gerado pela aplicação, como um UUID. Isso reduz riscos de sobrescrita de arquivos e uso de nomes maliciosos para sua aplicação.

flowchart TD
    A[Usuário envia o arquivo] --> B[Servidor grava os bytes no storage]
    B --> C{Tamanho gravado é<br/>igual ao informado?}
    C -- Sim --> D[Upload aceito]
    C -- Não --> E[Upload rejeitado]
    E --> F[Apaga o arquivo parcial<br/>do storage]

Validar o conteúdo real do arquivo, não o que ele diz ser

Complementando um pouco o tópico anterior, essa é uma parte interessante, por exemplo, o que pode acontecer é o usuário enviar um arquivo informando uma extensão e Content-Type de .pdf mas o MIME type do conteúdo indica que se trata de um arquivo .png, mais uma divergência das informações e uma possível vulnerabilidade para o sistema.
Para identificar o real conteúdo de um arquivo, se é uma foto .png, .jpeg, vídeo .mp4, áudio .mp3, podemos verificar os primeiros bytes do conteúdo. Eles indicam o verdadeiro tipo de arquivo quase como uma assinatura mesmo, então mesmo que você renomeie o arquivo e mude a extensão o conteúdo vai ser o mesmo.
Um teste rápido: pegue um arquivo .png qualquer real e use a ferramenta xxd no Linux. Note que os primeiros bytes retornados são 8950 4e47, renomeie esse arquivo para "sexta.pdf" e verifique novamente, os bytes serão os mesmos, é uma curiosidade bem legal.

flowchart TD
    A["Usuário envia shell.png"] --> B[Servidor lê os primeiros bytes<br/>do arquivo]
    B --> C[Detecta o tipo real<br/>pela assinatura]
    C --> D{Tipo real bate com<br/>o informado?}
    D -- Sim --> E[Upload segue o fluxo]
    D -- Não --> F[Upload rejeitado]

Mostrando um pouquinho de código, como o Laravel é um Framework bem completo, é até simples fazer essa validação dentro um FormRequest, segue o exemplo abaixo:

use Illuminate\Validation\Validator;

public function withValidator(Validator $validator): void
{
    $validator->after(function (Validator $validator) {
        $file = $this->file('file');

        if (! $file || ! $file->isValid()) {
            return;
        }

        $clientMime = $file->getClientMimeType();
        $contentMime = $file->getMimeType();

        if ($clientMime !== $contentMime) {
            $validator->errors()->add(
                'file',
                'O MIME type informado não corresponde ao conteúdo do arquivo.'
            );
        }
    });
}

Convergência entre dois sistemas(Storage e Banco)

No primeiro tópico, falei sobre evitar registros órfãos no sistema algo que pode acontecer caso o arquivo seja salvo no storage mas por algum motivo o insert no banco falhar, ou também o contrário disso.
Para isso é importante manter o Storage e o Banco de dados em sincronia quanto ao estado de um registro.
Acredito que a ordem de salvar primeiro o arquivo no storage e, depois, registrar os metadados no banco de dados seja a mais apropriada, para caso o insert falhe faça a limpeza do arquivo no Storage.

flowchart TD
    A[Salva o arquivo no storage] --> B[Insere o registro no banco]
    B --> C{Insert funcionou?}
    C -- Sim --> D[Arquivo e registro em sincronia]
    C -- Não --> E[Apaga o arquivo do storage]
    E --> F[Nenhum órfão fica no sistema]

Storage privado exige entrega mediada

Quando você vai entregar um arquivo ao usuário por um link, isso não é simplesmente entregar a URL do storage para acessar o arquivo diretamente. Isso impossibilitaria a aplicação de regras de acesso, senha e expiração, além de poder expor arquivos.
Por isso, o acesso por link deve passar pela a aplicação, para sejam aplicadas essas validações de regras de negócio antes de disponibilizar o arquivo.

flowchart LR
    A[Usuário acessa o link] --> B[Aplicação]
    B --> C{Regras válidas?<br/>expiração, senha, downloads}
    C -- Não --> D[Responde com erro<br/>ex.: 404]
    C -- Sim --> E[(Storage privado)]
    E --> F[Aplicação devolve<br/>o arquivo ao usuário]

Expiração não é o mesmo que limpeza

Expiração é um estado do arquivo no sistema, o arquivo não é mais disponibilizado pelo servidor, então a tentativa de acesso por link é inválida.
Limpeza é a ação de apagar o arquivo do armazenamento e seus metadados do banco de dados.
A limpeza não precisa ser feita no momento em que o arquivo expira, ela pode ser feita por um cron job periódico, como a entrega é mediada pela aplicação a tentativa de acesso por link retornaria um erro 404.
Logo, um arquivo pode estar expirado, mas ainda existir no armazenamento até que uma ação de limpeza o exclua.
Para a limpeza no Laravel, utilizei um Schedule simples diário e a trait Prunable que facilita a exclusão de registros.

Vou deixar trechos de código da implementação e seguem os links da documentação para ver mais sobre: pruning-models e schedule.

/**
 * Define a query que seleciona arquivos expirados para remoção.
 *
 * @return Builder<static>
 */
public function prunable(): Builder
{
    return $this->newQuery()->where('expires_at', '<=', now());
}

/**
 * Exclui o arquivo armazenado antes de remover seus dados do banco.
 */
protected function pruning(): void
{
    if (! Storage::disk($this->disk)->delete($this->path)) {
        throw new RuntimeException("The expired file [{$this->id}] could not be deleted.");
    }
}

// E o schedule diário para a limpeza
Schedule::command('model:prune')->daily();

Considerações finais

Foi muito legal estudar um sistema open-source que uso no dia a dia, além de criar um sistema com essa finalidade e aprendendo mais funcionalidades do Laravel, espero que esse artigo tenha lhe ajudado de alguma forma.

Referências

Waifuvault, o projeto que estudei: https://waifuvault.moe/
Resumo dos meus estudos: https://github.com/matheusdsilva01/learning/tree/main/about-waifuvault
Guia de segurança da OWASP sobre envio de arquivos:
https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html
Projeto que desenvolvi: https://github.com/matheusdsilva01/temp67

Feature-based: por que sua pasta components virou uma bagunça?

Matheus Silva — Fri, 21 Aug 2026 19:37:54 +0000

Acho que todo dev já passou pelo momento de se deparar com um projeto e se perder no meio de tantos arquivos. Isso pode ser resultado de N fatores, e um deles pode ser a forma como o projeto está organizado.

Falando especificamente de frontend, quando criamos um projeto do zero em qualquer framework, ele vai lhe entregar uma estrutura padrão, chamada de Type-based em que você consegue desenvolver coisas simples, nada muito complexo ou escalável. Você vai conseguir seguir essa estrutura inicial e entregar as features necessárias, e é isso.

Até certo ponto, beleza: tudo funciona, você consegue se localizar entre as pastas e arquivos. Aí você vai integrando mais endpoints da API, adicionando features, novos fluxos, e então as coisas ficam entrelaçadas, distantes e muito desorganizadas. Implementar uma feature nova já não é tão simples, e se localizar é pior ainda.

Por que essa dor?

Isso foi uma experiência própria que vivi em projetos que desenvolvi, e que despertou minha curiosidade sobre como estruturar melhor meus projetos. Aí encontrei algumas possibilidades de arquiteturas, como DDD, Clean Architecture, MVC e Micro-frontend. Mas muitas delas eram voltadas para projetos backend, eu não via com bons olhos trazer isso para o frontend moderno e também me pareciam soluções muito complexas para algo simples.

Uma solução... Simples?

Foi aí que encontrei uma solução chamada Feature-based. É uma abordagem que parece simples, em resumo: você pega seu projeto e quebra em partes. Que partes? Bom, aí pode ser por entidade, domínio, etc. Essa quebra traz algo interessante, que é a modularidade: seu sistema agora está mais desacoplado, cada parte passa a ser autogerenciável, tem sua própria responsabilidade e seu propósito bem definido.

Dando um exemplo visual antes de seguirmos:

src/
├── features/
│   ├── movies/
│   │   ├── components/
│   │   ├── hooks/
│   │   ├── api/
│   │   └── types/
│   ├── comments/
│   │   ├── components/
│   │   ├── hooks/
│   │   ├── api/
│   │   └── types/
│   └── auth/
│       ├── components/
│       ├── hooks/
│       ├── api/
│       └── types/
├── shared/
│   ├── components/
│   ├── hooks/
│   └── utils/
└── app/
    ├── routes/
    └── layout/

Prós e contras

Os prós? Organização: Você consegue identificar com facilidade onde trabalhar. Testabilidade: Seus fluxos de testes de e2e, integração e unitários ficam melhor localizados. E escalabilidade: Surgiu um fluxo novo? Para qual feature? Altere o código na pasta da feature que vai receber a implementação. Surgiu uma feature, entidade nova? Literalmente crie uma pasta nova em features... ou não. Acredito que aqui é um bom momento para falar dos contras.

Dando um contexto para facilitar o entendimento: imagine um cenário em que vamos adicionar os nomes das empresas produtoras na página de detalhes de um filme. Primeiro pensamento: nova entidade companies, logo vamos criar uma pasta nova de companies em features. O backend vai ter um endpoint /companies?movie_id=?, jogamos isso dentro de companies e movies vai importar o que for necessário dali. Resolvido, isso está errado? Não, é um excelente caminho e segue os requisitos para ser uma feature nova no projeto. Mas, nesse momento, é somente uma chamada para a API que retorna uma lista simples. Outra possibilidade, que também não estaria incorreta, é um simples getMovieCompanies dentro de features/movies — nesse momento é aceitável. Mas, caso companies ganhe mais fluxos e telas no projeto, aí o próximo passo é mover essa lógica para dentro de features/companies.

"Como isso se encaixa em um contra?" Aqui entra o ponto de maturidade para tomar esse tipo de decisão de implementação e levar em conta os trade-offs — nesse caso, o trabalho de criar uma nova feature versus a simplicidade do momento, em troca de uma possível refatoração no futuro. Obviamente esse exemplo é bem simples, usado só para ilustrar um cenário que poderia acontecer em um projeto real.

Conclusão

Com a IA muito presente no dia a dia de desenvolvimento, acredito que ter essa preocupação com a estrutura do projeto é importante. Sem uma estrutura bem definida, é fácil um agente duplicar lógica sem você perceber e só acabar aceitando o que foi gerado porque, aparentemente, está tudo funcionando como esperado

É isso, tem mais pontos que podem ser abordados como circular dependency, deep import, arquivos compartilhados mas isso já é um bom introdutório para pensar sobre como organizar seus projetos.
Se quiser se aprofundar mais sobre o assunto deixo aqui um pouco do que foi meu estudo sobre esse tópico contém alguns resumos e lições sobre testes, definição de features, discussões mais técnicas sobre implementação e você pode encontrar alguns exemplos de código sobre Feature-based: https://github.com/matheusdsilva01/learning/tree/main/learning-feature-based

Espero que isso tenha lhe incentivado a estruturar melhor seus projetos e tmj

Referências

https://github.com/alan2207/bulletproof-react/

Porque o PostgreSQL é tão queridinho?

Matheus Silva — Tue, 23 Jun 2026 19:30:46 +0000

Introdução

PostgreSQL é um dos bancos de dados relacionais mais populares no mundo por alguns motivos e tudo isso começou como um simples projeto de faculdade, hoje sendo a principal ferramenta adotada por grandes projetos e empresas no mundo.
E neste artigo vou dar um pouco de contexto de como ele alcançou esse posto.

Historinha
Open source
Extensões
Confiabilidade
Comparativo
Conclusão

Historinha

Contando um pouco de historia, o PostgreSQL nasceu dentro da universidade de Berkeley nos Estados Unidos ja com o objetivo em extensibilidade e suporte a tipos de dados complexos, como pesquisa científica inicialmente chamado de apenas Postgres. E foi crescendo, mais tarde tendo suporte para SQL sendo nomeado como PostgreSQL e lançado para web ganhando performance e mais manutenção.

Open source

O PostgreSQL não tem um único dono, hoje é mantido pela PostgreSQL Global Development Group um agromerado de empresas e desenvolvedores que contribuem para o projeto sem o poder de tomada de decisões de forma unilateral sobre o projeto.

Extensões

Graças a compatibilidade com extensões é possivel usar o PostgreSQL para vários propósitos algumas extensões famosas são:

PostGis: A possibilidade de processamento de dados geográficos e espaciais.
pgvector: Para uso de Inteligência Artificial o pgvector possibilita a busca vetorial em embeddings.

Confiabilidade

A partir de 2001 se tornou ACID(Atomicidade, Consistência, Isolamento e Durabilidade) garantindo segurança, robustez e confiabilidade para os usuários. Também possui mecanismo de MVCC(Multi Version Concurrency Control) para não bloquear ações de leitura e escrita otimizando paralelismo e garantindo performance em ambiente com grande tráfego.

Comparativo

Mesmo levando em consideração outras opções conhecidas do mercado como MySQL, Oracle e até mesmo não relacional como MongoDB, PostgreSQL ainda tem uma grande aceitação para uma aplicação que seja pequena ou grande porte.

Critério	PostgreSQL	MySQL / MariaDB	MongoDB	Oracle DB
Paradigma	Relacional (Objeto-Relacional)	Relacional	Documento (NoSQL)	Relacional
Licença	Open Source (Permissiva)	Open Source (GPL) / Comercial	Source-available (SSPL)	Proprietária (Muito cara)
Extensibilidade	Excelente (UDFs, Extensions, FDW)	Limitada	Limitada	Excelente, mas proprietária
Suporte a JSON	Excelente (`jsonb` indexado)	Bom	Nativo	Bom, mas complexo
Principais Usos	Sistemas financeiros, IA, GIS, aplicações robustas de qualquer porte	Aplicações web tradicionais, WordPress, e-commerces simples	Protótipos rápidos, catálogos flexíveis, dados semi-estruturados	Grandes corporações legadas, ERPs de altíssima escala

Conclusão

Se você precisa de segurança, flexibilidade e robustez, o PostgreSQL faz por merecer esse posto de queridinho.

O básico para gerenciar e se proteger de vulnerabilidades em dependências no seu projeto Node.

Matheus Silva — Mon, 20 Apr 2026 19:20:05 +0000

Verificar e eliminar vulnerabilidades em dependências pode ser mais simples do que você imagina e lhe garanto que isso pode salvar seu tempo e te livrar de algumas dores de cabeça no futuro.

Antes de tudo, é importante saber gerenciar as dependências do seu projeto e entender como o seu gerenciador de pacote faz uma parte do trabalho para você, nesse artigo vou abordar os seguintes tópicos:

SemVer
Relação entre package.json e package-lock.json
Lidando com vulnerabilidades
Conclusão

Antes de falar sobre as vulnerabilidades em si, acho importante uma explicação básica sobre o que significa a sigla SemVer (Semantic Version) e como funciona a relação do package.jsoncom o package-lock.json

SemVer

SemVer, ou Versionamento Semântico, é uma especificação para ajudar desenvolvedores a entender as mudanças e atualizações durante o versionamento de pacote.

Uma versão de pacote é definida em 3 números Major.Minor.Patch (ex: 2.3.14), bom o que significa cada número desse:

Major (2): Uma versão com atualizações que não tem compatibilidade com versões major anteriores. Então se você atualizar da 1.0 para 2.0 pode ser que isso cause algum problema quando você executar seu projeto, seja por alguma funcionalidade obsoleta ou alguma mudança na sua utilização, etc.
Minor (2.3): Uma versão que adiciona recursos que tem compatibilidade com versões minor anteriores, ou seja, atualizações dentro da mesma versão major não devem quebrar seu sistema.
Patch (2.3.14): Normalmente uma versão para lançar correções de bugs, vulnerabilidades e claro mantendo compatibilidade com versões de patch anteriores.

Aqui não tem muito segredo, então quando você ouvir algo do tipo “tal pacote já lançou uma versão de patch(x) pra corrigir aquela vulnerabilidade da V14.3” é uma versão 14.3.x (entenda x como qualquer número).

Intervalo de versões (^, ~)

Algo fora dessa especificação são os sinais de circunflexo ^ e til ~ , que você comumente verá em projetos, são usados para definir intervalo de versões e sinalizar para o npm como ele deve lidar com as atualizações da dependência.

^ circunflexo

Permite atualizações até versões minor mas não major, por exemplo: 2.3 pode atualizar para 2.4 mas por conta própria não vai fazer uma atualização de versão para major 3.x

~ til

Permite atualizações apenas de versões patch dentro da minor especificada, por exemplo: 2.3.14 pode atualizar para 2.3.20. E claro não vai atualizar para uma versão 2.4

Também é possível não especificar um intervalo de versões, dessa forma a instalação é fixada em uma versão e só pode ser alterada manualmente com uso do npm install por exemplo.

Definir um intervalo de versões vai trazer mais segurança e praticidade quando precisar dependências mas caso precise de um controle mais rígido pode travar em uma versão sem problemas.

Relação entre package.json e package-lock.json

São arquivos que se completam.

O package.json salva as dependências do projeto, é onde você vai ter um overview geral e pode definir o intervalo de versões.

O package-lock.json é quem vai controlar a árvore de dependências e definir qual a versão exata que vai ser instalada, claro seguindo a referência definida no package.json, garantindo que todas as instalações tenham as mesmas versões de dependências, por isso é muito importante você manter o package-lock.json commitado/salvo no seu repositório além de deixar processo de instalação mais rápido vai dar consistência entre diferentes ambientes.

Lidando com vulnerabilidades

O npm nos forcene basicamente duas funcionalidades para identificar e resolver vulnerabilidades em nossas dependências.

npm audit e npm audit fix

Para verifica se as versões instaladas das dependências no projeto contém alguma vulnerabilidade conhecida, npm audit eu diria que é o primeiro passo. Executar esse comando no seu terminar vai gerar algo como:

Nesse exemplo estou com a versão 16.1.6 do Next, aqui o relatório indica que nesse projeto só tenho vulnerabilidade nessa dependência e essa versão está dentro de um range de 6 vulnerabilidades conhecidas e como pelo menos uma delas tem gravidade de nível high a gravidade geral é essa, mesmo se algumas delas tiverem nível menor, também retorna links com mais informações sobre elas.

Para eliminar essas vulnerabilidades, como no meu package.json defini o pacote do Next como ^16.1.6 (olha o ^) e existe uma correção para essas vulnerabilidades dentro desse intervalo de versão definido, isso permite que apenas executando npm audit fix ele atualize a dependência para uma versão sem vulnerabilidades.

Aqui foi feita uma atualização para 16.2.4 mas e se tivesse definido com ~ ? Fica aí a lição de casa.

Conclusão

Escrevi esse artigo com o propósito de fixação do conteúdo que estudei e deixo aqui alguns tópicos para se aprofundar sobre o assunto.

Dependabot
.npmrc (save-exact, audit-level)
Snyk

Referências:

https://www.youtube.com/watch?v=kK4Meix58R4

https://semver.org/lang/pt-BR/

https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-json

Controlando cache através do navegador

Matheus Silva — Fri, 12 Dec 2025 21:22:10 +0000

Cache você já deve ter ouvido esse termo várias vezes e recentemente resolvi aprender como o navegador implementa esse mecanismo e então resolvi escrever esse post sobre o que aprendi.

Contextualizando, Cache é um mecanismo utilizado com a finalidade de trazer velocidade ao acesso um conteúdo que é frequentemente utilizado.

Quando estamos implementando cache em nosso sistema é importante mantê-lo o mais próximo possível do cliente e para isso podemos usar o sistema de cache dos navegadores assim mantendo velocidade no acesso ao conteúdo e salvando recursos de nossos servidores.

Tipos de cache

Para gerenciar cache no navegador usamos o header Cache-Control e podemos trabalhar com os seguintes valores para ele:

default

Por padrão o seguinte fluxo será seguido:

Se for encontrada em cache uma versão atualizada dos dados essa será retornada.
Caso seja obsoleta será feita uma espécie de consulta ao servidor e verificar se os dados do cache sofreram alterações, se sofreram alteração os dados atualizados vão ser retornados e atualizados no cache, caso contrário o dado do cache será retornado.
Se não for encontrado nada em cache será feita a requisição ao servidor e o cache vai ser atualizado com os dados retornados.

no-store

O navegador vai ignorar o cache, efetuar a requisição para o servidor e não irá armazenar o retorno no cache.

reload

O navegador vai ignorar o cache, efetuar a requisição para o servidor e vai atualizar o cache com o retorno da requisição.

no-cache

O navegador verifica no cache se existe alguma versão atualizada dos dados ou obsoleta depois disso é verificado com o servidor se há uma nova versão dos dados, se houver será retornado a nova versão pelo servidor e o cache será atualizado, se não a versão do cache vai ser retornada.

force-cache

O navegador verifica o cache, se encontrar uma versão atualizada ou obsoleta dos dados ela vai ser retornada se não encontrar nada no cache ele vai fazer a requisição normalmente no servidor retornando os dados e salvando no cache.

max-age=<valor em segundos>

Pode ser usado em conjunto com os valores acima e define por quanto tempo aquele dado é definido como “atualizado”.

Também e possível gerenciar o cache usando o header Expires que pode ser definido com um tempo específico, exemplo: Expires: Thu, 25 Dec 2025 18:18:18 GMT ou seja a partir do tempo especificado aquele dado passa a ser obsoleto.

Esse foi o conteúdo que estudei espero que tenha agregado de alguma forma. 😊

Referências:
https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Guides/Caching
https://developer.mozilla.org/en-US/docs/Web/API/Request/cache

DEV Community: Matheus Silva

5 lições de segurança que aprendi estudando um host temporário de arquivos

Não confie no que é enviado pelo usuário

Validar o conteúdo real do arquivo, não o que ele diz ser

Convergência entre dois sistemas(Storage e Banco)

Storage privado exige entrega mediada

Expiração não é o mesmo que limpeza

Considerações finais

Referências

Feature-based: por que sua pasta components virou uma bagunça?

Por que essa dor?

Uma solução... Simples?

Prós e contras

Conclusão

Referências

Porque o PostgreSQL é tão queridinho?

Introdução

Table of contents

Historinha

Open source

Extensões

Confiabilidade

Comparativo

Conclusão

O básico para gerenciar e se proteger de vulnerabilidades em dependências no seu projeto Node.

Table of contents

SemVer

Relação entre package.json e package-lock.json

Lidando com vulnerabilidades

npm audit e npm audit fix

Conclusão

Referências:

Controlando cache através do navegador

Tipos de cache